I've have been pretty quiet lately.  Actually, I've been quite busy and it turns out that there isn't much new to share.  However, this is one thing that comes to mind.

A recurring pattern in my UI is selection criteria that can applied to a GridView.  It turns out that frequently the same criteria applies to various screens.  I use LinqDataSources to bind to DropDownLists for many of the criteria.

It is not uncommon to use one controller for every page.  Following this approach, I ended up with the same data being published by multiple controllers.  I started considering ways to reduce or eliminate the duplication between the controllers.  I had two major considerations (at first): inheritance and splitting out a new controller to be consumed by the UI.

Inheritance can be a useful tool, but it can be overused as well.  I knew I could easily reduce the duplication with a base controller class, but this design didn't sit well with me.  The base class would be providing data, not behavior.

I then turned to the idea of introducing a stand-alone controller just for selection criteria.  In this case, the UI would reference two controllers, one for the criteria and one for the rest of the page.  It is not uncommon to have two or more controllers driving one page.  I liked this idea, then I realized something.  The new controller didn't look like a controller at all.

The new criteria controller didn't control anything.  It simply passed data from the data context to the UI, nothing more.  In fact, there was no need for a "view" in the traditional sense.  This might sound strange, but the driving force behind all of this is the LinqDataSource.  Using the LinqDataSource is completely different than the traditional DataSource/DataBind combination.  With the LinqDataSource, you simply configure the control and it retrieves the data on its own.   Push versus pull.

So, when using a LinqDataSource, my UI was pulling data from the controller, as opposed to the controller pushing data to the view via an interface.  The LinqDataSource does not lend itself to the MVC pattern.  Nor do ObjectDataSource and SqlDataSource for that matter.

What I finally decided on was allowing my view / page to access the data context directly.  I simply exposed a couple of read only properties that represent collections of entity objects that the UI needs for the selection criteria.

The conclusion?  The MVC pattern is great.  However, sometimes it isn't worth all of the extra lines of code.  Don't put blinders on and think that everything related to the UI has to fit into the MVC pattern.
Simple questions to ask yourself... Am I over complicating this?  What is the simplest thing that works?

posted on Wednesday, April 2, 2008 8:49 AM
Filed Under [ Agile .Net Design Design Patterns ASP.Net Design Principles ]


No comments posted yet.

Post A Comment