How ugly is this solution?

I guess this can be called an anti-pattern, but it sort of works if you have a really small solution and no other coders than yourself :)

 Imagine having a web form, which has a label control on it and this web form also loads a user control during run-time. The user control has a single button on it and when pressed, the button should set the text value of the label to the current date and time.

Now, there are some good ways and some bad ways to send data from a child control to a parent control, and I usually use events for this. Another way of doing this would be to access a property in the parent directly from the child control, but personally I think this is a really ugly way of doing things. How ugly do you think this is?

In the web form, add a public property to be able to set the label text:


protected System.Web.UI.WebControls.Panel Panel1;

protected System.Web.UI.WebControls.Label Label1;


private string mylabel = null;


public string Mylabel


           get { return mylabel; }



               mylabel = value;

               this.Label1.Text = mylabel;




In the user control, the Page property of the control (which always points at the parent page, not the parent control) into the correct WebForm class, then set the public label property we define above directly.


private void Button1_Click(object sender, System.EventArgs e)


           if(this.Page is WebForm1)


                      WebForm1 form = (WebForm1)this.Page;

                      form.Mylabel = "Time is " + DateTime.Now;




This code seems to work pretty well, but I bet some of you get a nasty feeling in your gut when seeing code like this, and I agree completely. First of all, in an event driven enviroment, a control should never mess with properties in its parent/container. Secondly, the control assumes that the parent is always of a certain type (WebForm1) with a public property called Mylabel. I'm sure there are other good reasons for not coding like this. Comment please :)



  • I would suggest either making the label itself a part of the usercontrol, or bubbling the button.Click event from the user control to the page. If you use the second method, you should create a custom eventargs class to pass through the event handler which would contain your new label text.

    As to your MyLabel property on the page, I'd dispense with the private mylabel string altogether and just wrap the Label control with the MyLabel property.

    public string MyLabel


    get { return this.Label1.Text; }

    set { this.Label1.Text = value; }


    I find this approach useful when I want the UI to implement the interface of the object its supposed to be viewing / editing. For instance, If I have an IPerson Interface, I write my DataAccess object such that the Save() method receives an instance of IPerson as an argument. If the WebForm implements IPerson, then when the user has made their changes, I can simply pass the entire WebForm to the Save() method because it IS an IPerson.

  • I looked at your Model/View/Presenter, and it is similar to what I'm doing as far as the relationship of the UI to the Business Object is concerned. I'm not sure what your "Presenter" is for though.

  • The Model/View/Presenter pattern looks good if you want to really abstract the different layers and I guess it will make automatic testing of the UI easier.

    But you still have the problem of having a child control accessing a property in the parent container, something I personally don't like. Alright, if you KNOW that all your containers implement a certain interface (like your IMyView), you're fine. But you never know with some new developer comes aboard and tries to use your controls in other parts of the system. Well, you see my point.

    I'll post a simple sample of how I use events. I prefer the standard ASP.NET event model for solutions like this.

  • "But you never know with some new developer comes aboard and tries to use your controls in other parts of the system."

    Of course, even with the best laid designs, you can have some developer come in and increase the coupling. This is where documentation and education would come in.

    The developers would also need to take a little time and familiarize themselves with the project rather than just hacking and banging on something until maybe it works. Unfortunately, this is all too common in our field.

Comments have been disabled for this content.