David Hayden [MVP C#]

Jeff Perrin has some excellent comments regarding my previous post describing the GRASP Controller Pattern, which essentially answers the question as to what first object beyond the UI layer is responsible for receiving and coordinating a system operation.  In this post, I talked about how the DotNetNuke Architecture and Community Server Architecture made use of the Controller GRASP Pattern that is described in Applying UML and Patterns by Craig Larman.

Jeff is questioning my use of the word "Controller" in my examples and points to a post on his blog where he discusses the Page Controller pattern.  He provides an example of the Page Controller pattern that I have copied below for the sake of discussing it.

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

{

     LoadEntity();

}

private void LoadEntity()

{

     User user = new User();

     if( this.RequestedEntityID > 0 )

     {

           user.ID = this.RequestedEntityID;

           BrokerFactory.Fill( user );

      }

      EntityControl cont = 
        (EntityControl)LoadControl( "EditStaff.ascx" );

      cont.BoundEntity = user;

      this.phEntity.Controls.Add( cont );

}

In Jeff's post, he breaks down the Model-View-Controller roles as such:

• Model: Your business class (ie; a User class)
• View: A UserControl
• Controller: Your code-behind class for the requested page

This is a great example of the Page Controller pattern, but so far, none of this applies to the GRASP Controller Pattern as we are still in the UI-layer, and the GRASP Controller sits in the domain layer.  The question becomes, what is the BrokerFactory class that shows up in Jeff's example?

I think BrokerFactory is the GRASP Controller that Craig Larman is talking about.  Although Jeff doesn't provide any code for it, I am guessing that this class is not much different than the following 2 controller classes shown below that I talked about in DotNetNuke and Community Server, respectively.  I am guessing BrokerFactory is in the domain layer and does nothing more than possibly check the cache for an instance of the user, and if not there, just hands the request off to the appropriate data provider.

Public Function GetHtmlText(ByVal moduleId As Integer) As HtmlTextInfo

    Return CType(CBO.FillObject(DataProvider.Instance().GetHtmlText(moduleId),
                    GetType(HtmlTextInfo)), HtmlTextInfo)

End Function

public class WeblogPosts
{
    private WeblogPosts(){}
    
    // ...

    public static PostSet GetPosts(BlogPostQuery query, bool cacheable)
    {
        string key = cacheable ? query.Key : null;
        PostSet ps = null;
        
        if(cacheable)
            ps = CSCache.Get(key) as PostSet;

        if(ps == null)
        {
            WeblogDataProvider wdp = WeblogDataProvider.Instance();
            ps = wdp.GetPosts(query);

            if(cacheable)
                CSCache.Insert(key,ps,30,System.Web.Caching.CacheItemPriority.Low);
        }

        return ps;
    }
    
    // ...
}

It certainly seems to fit the model.  BrokerFactory seems to be a facade controller as explained in Applying UML and Patterns.  It essentially provides us an entry point into the domain layer and basically does nothing but delegate work to other domain objects.

I would love to hear from anyone else as to whether this seems reasonable or is totally off the mark :)