User Controls are handy when working in web forms, but what a mess they can generate. I was asked what to do when UCs are used and some dependencies need to be injected during the construction - but UCs are a bit tricky in regards to construction. So the possibilities are:

1. Use new operator and instantiate a user control (Web Application Project) - no good as the visual elements residing on the designer surface (.ascx) then not loaded.

2. Use Page.LoadControl(<path>) - but no option to pass in parameters.

3. Use Page.LoadControl(<type>, params object) - not strongly typed.

So all these possibilities are nice, but not helping to use a load with strongly typed parameters. Then the idea proposed at one of the replies with almost the same question was to use a static factory. I tried to play with the idea and this was a result.

Step 1 - create the UC

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="SomeUserControl.ascx.cs" 
Inherits="LoadControlWithFactory.SomeUserControl" %>
<asp:TextBox runat="server" id="txtName"></asp:TextBox>

Step 2 - create the code behind with static factory method

   1:    public partial class SomeUserControl : UserControl

   2:    {

   3:      private string name;

   4:   

   5:      protected override void OnLoad(EventArgs e)

   6:      {

   7:        base.OnLoad(e);

   8:        txtName.Text = name;

   9:      }

  10:   

  11:      public static SomeUserControl Create(string name)

  12:      {

  13:        SomeUserControl some = 
       ((Page)HttpContext.Current.Handler).LoadControl("~/SomeUserControl.ascx") as SomeUserControl;

  14:        some.name = name;

  15:        return some;

  16:      }

  17:    }

Note: the underlined code has a bad smell - but that was the only idea I had to gain access to the currently executed page. Any other ideas are welcomed.

Step 3 - load UC dynamically through the code with injected data

   1:    public partial class _Default : System.Web.UI.Page

   2:    {

   3:      protected override void OnPreRender(EventArgs e)

   4:      {

   5:        base.OnPreRender(e);

   6:        phContent.Controls.Add(SomeUserControl.Create("Sean Feldman"));

   7:        phContent.Controls.Add(SomeUserControl.Create("Anna Feldman"));

   8:      }

   9:    }

Conclusions

What it seems is that this allowed a few more things than just a pattern implementation. It allowed:

1. DRY principle - rather than replicating the .ascx path wherever UC is loaded, this information is now stored and encapsulated inside the factory.

   LoadControl("~/SomeUserControl.ascx") as SomeUserControl; // for Sean
   LoadControl("~/SomeUserControl.ascx") as SomeUserControl; // for Sean

2. Simplicity - Drop Dead Simple principle (well, this is something I like to apply recently to the code to make is easy to digest, so this is the name I came up with).

   SomeUserControl.FactoryMethod(<typed params>);

3. Maintainability - simple and affordable.

Update 2007-12-17: I have re-arranged slightly the post to minimize clipping and attached the code.

While discussing with JP Boodhoo why he stopped to use the I notation for the interfaces, I think we got to the point where it was clear why would someone drop the "I" or opposite, adopt it.

As a developer, I want to differentiate between a pure abstraction and a concrete thing. So to ease on ourselves, we put the I as a differentiation, rely on the visual interpretation that our brain (little one in my case) is doing ("association" as against to "memorization"). And that would be the justification of using the "I" notation.

Now, if we look at the same issue from a more real-world perspective - bicycle. A bicycle is an abstraction, a 3-wheel or mountain bicycle are something concrete.   So having something like:

   1:  class MountainBicycle : Bicycle

   2:  {

   3:  }

Is nothing but

   1:  class MountainBicycle : IBicycle

   2:  {

   3:  }

With a difference that you know that bicycle is an abstract thing and if your brain is trained enough about it, then you do not need to have an "I"-hint to trigger the "association".

Personal note: so far, from the comments to my previous post on this, I have not seen that direction. Does this mean we are "boxed" to a particular thinking and not willing to evaluate other options as a community (.NET)?...

PS: "Hey, what about Customer sample?" you might ask - never too late to admit - I was wrong. Customer is not concrete, therefor it's an interface, what concrete is a CertainTypeOfCustomer or any other deviation of customer :)

While reading  R.C. Martin's book converted to C# by M. Martin "Agile Principles, Patterns, and Practices in C#" I could not ignore the fact that the Java notation for interface naming was used all over the place. Trying to be open-minded (or should I use "pragmatic" these days) I want to pop a question what is the benefit of dropping the I-prefix and how it does or does not influence the daily work.

For myself, having an "I" prefix in front of the name not only tells me that this is an interface, but also that this is a pure "contract" (Design by Contract is something I start to like).

   1:  public interface ICustomer

   2:  {

   3:    // ...

   4:  }

   1:  public interface Customer

   2:  {

   3:    // ...

   4:  }

So what do you have to say about it? To "I" or not to "I"?