Application design, separated logic, delegate or not

Question

Delegates, would those apply here? If so, how? Code examples, as I am new to this area.

Logic separation is what I am intending to implement and I think my task below would be a perfect candidate. I have read that objects should be fairly independent and not hard wired to one another.

ASPX (Page)

<uc1:Attachment ID="Attachment1" runat="server" />
<asp:Button ID="Button1" runat="server" Text="Button" onclick="Button1_Click" />

ASPX.cs (Codebehind)

protected void Button1_Click(object sender, EventArgs e)
{
  // Check the files and upload
}

ASCX (UserControl)

<MyControl:Upload ID="Upload1" runat="server" 
AllowedFileExtensions=".zip,.jpg,.jpeg,.doc,.gif,.png,.txt"
    MaxFileInputsCount="3"
    OverwriteExistingFiles="false"  
onfileexists="Upload1_FileExists" 
onvalidatingfile="Upload1_ValidatingFile" />

ASCX.cs (Codebehind)

public Upload AttachmentControl
{
    get { return this.Upload1; }
}

The task above is a file upload module. The control that does the upload is in a UserControl which has been dragged on to an ASPX page.

The Submit button on the ASPX page should start the file upload process. This should be a fairly common scenario where the Page saves other information to a database and also upload files.

My instinct from past experience was to expose the Upload control in the UserControl via a public Property. This would tie the Attachment UserControl to the the page.

How can I untie this, perhaps the use of delegates?

Answer 1

What information does the view need about its Attachment control? What does the Attachment control need to know about the view which contains it?

I suppose a delegate(Stream uploadContent) could let you decouple this farther, but if you're using the System.Web.Page model... the motivation to decouple things that far seems lacking.

Having the view accept a callback inverts the appropriate path of dependency in your application, doesn't it?