I am working on a full fledged product comprising many modules to automate a wide array of human resources management related activities. Since we are developing a commercial product, we have to be very cautious in its initial architecture and design.

Though we focused primarily on meeting different and complex business requirements but enough consideration was given using latest technologies and architectures. Main requirements were (all of them are standard for any commercial product):

   1. The product should be highly scalable and easy to maintain and enhance with new features.
   2. The entire architecture should be SOA based.
   3.  Every  layer should be loosely coupled with proper separation between

(a)    GUI and Business Logic (BL)

(b)   BL and Data Access Layer (DAL)

(c)    GUI and DAL

For the BL, we modified the CSLA.NET framework (stripped it down, modified it to make it more flexible, changed/removed many features). But I was stuck in the GUI design in ASP.NET: to facilitate code reuse and separation between GUI and Business Logic through the controller two design patterns: Page controller and Front Controller.
 

Basically I wanted that there should not be much logic in code behind classes, instead the logic should be put in separate files and accessed via a centralized controller so that code can be re-used and the future maintenance becomes easier. There would be a command factory which would instantiate appropriate command based on Action and call the service interface methods which in turn would expose the domain model for further business logic processing. Simple and easy MVC implementation.
 

Now, when coming to GUI and BL separation in ASP.NET, I had two options: FrontController(FC) and PageController (PC). I should admit that I am not a very experienced architect and am still in the process of learning things. Through my struts experience, I already knew that Struts is FrontController based, but ASP.NET by default is Pagecontroller based, with many cool features such as Postback.
 

When I had to decide which of these patterns to use, I had a tough time. Let me explain why:

Below is an abridged version of Pagecontroller Design Pattern from the book Patterns of Enterprise Application Architecture:

“..The main decision point is whether to use Page Controller or Front Controller (344). Of the two, Page Controller is the most familiar to work with and leads to a natural structuring mechanism where particular actions are handled by particular server pages or script classes. Your trade-off is thus the greater complexity of Front Controller (344) against the various advantages of Front Controller, most of which make a difference in Web sites that have more navigational complexity.”

Now, this made me decide in favor of FC based design. Here is more info on FC by Microsoft: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesFrontController.asp

On further more research (i.e. google search J) and found an interesting blog: http://www.jasonbock.net/JB/Default.aspx?blog=entry.7e9a7c868d86441196d21980e570dadd

I seemed to agree with the thoughts presented in this blog and also reviewed frameworks such as Lattis and NStruts. But I was not satisfied. Reasons? Many!

 As soon as I started designing the initial skeleton classes for laying the groundwork, I realized many potential issues like problems with Postback, Viewstate etc. I did some research on Google and came to know that similar problems were faced by others but were managed somehow, but it is difficult to implement hardcore MVC2 approach in ASP.NET as it is by default page controller based. I didn’t feel like going full heartedly for FC based design now (frameworks such as Lattis were like pure FC based). When the ASP.NET has provided us a beautiful page controller based event driven model, why would I ignore (rather bypass) that completely and implement a http handler to direct all page requests to a controller. Of course I’ll have a lot of issues if I use such an approach, but is it really worth? Wouldn’t other developers have a problem understanding and coding for such a framework? Imho, pure FC based design was overkill for our project in ASP.NET.

I wanted a mixed approach: design should be front controller based but also use the page controller architecture of ASP.NET so that it becomes little bit easy to implement.

Instead of using Http handler, I thought of putting the code in a base page class in the GUI, which will parse the context object and build the arguments for a command which would be instantiated by a command factory class. Since I would be calling this base class method in the event handler of the page, I would have access to all postback and session state and I thought this is much more conducive to the asp.net framework. 

I am still working on this, and will post something new soon with some sample code.