Front Controller vs Page Controller

[jross]

In the past, I implemented a non-Spring MVC framework for ASP.Net. It handles events differently than Spring. Since I am not thoroughly familiar with Spring.Web, I wanted to understand the possibilities of using a FrontController versus the Page Controller pattern.

Spring.Web seems to use ASP.Net's built-in event handling which posts back to the Page. The non-Spring framework I currently use, rewrites the form action to always post to Default.aspx and uses a hidden input value to determine which event is to be processed. For example,

<form action="/Default.aspx" ...
<input type="hidden" name="evt" value="widget.updWidget">
...

All requests are handled via an httpModule which calls the core framework to do the following:

+ capture event key from request, e.g. evt=widget.updWidget
+ auto-load bean object with helper class to call setter methods
+ look up event (note that on app init, events detailed in xyzConfig.xml are cached in EventManager class)
+ dispatch event to listener --> call bean's validate method --> if success, call service (business object code) --> call dao and/or gateway as necessary --> return to listener
+ set result key based on outcome and use key to locate and build response

Can Spring.Web be used in a similar fashion? I hope this is somewhat clear. Thanks in advance for any insight and direction you can provide.

// ---------------------------------------------------------------------
// web.config
// ---------------------------------------------------------------------

<httpModules>
	<add type="CmsProject.MyHttpModuleA,CmsProject" name="MyHttpModuleA" />
</httpModules>


// ---------------------------------------------------------------------
// MyHttpModuleA.cs
// ---------------------------------------------------------------------

namespace CmsProject
&#123;
	public class MyHttpModuleA &#58; GenericApplication.CMSHttpModule, IHttpModule, IRequiresSessionState 
	&#123;
		GiGi.FrontControllerHandler controller = null;

		private void context_PreRequestHandlerExecute&#40;object sender, EventArgs e&#41;
		&#123;
			System.Web.HttpContext ctx = System.Web.HttpContext.Current;	

			// Brief description of MVC framework's controller.ProcessRequest&#58;

			// capture event key from request, e.g. evt=widget.updWidget
			// look up event &#40;on app init, events detailed in xyzConfig.xml are cached in EventManager class&#41;
			// dispatch event to listener --> call service &#40;business object code&#41; --> call gateway, dao as necessary
			// result key used to locate and build response

			controller.ProcessRequest&#40;ctx&#41;;
		&#125;
	&#125;
&#125;


// ---------------------------------------------------------------------
// widgetConfig.xml
// ---------------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>

<GiGi version="1.0">

	
	<properties>

		

		<property name="DB_WIDGET_WIDGETID_MIN_VALUE" value="1" /> 
		<property name="DB_WIDGET_WIDGETID_MAX_VALUE" value="2147483647" /> 
		<property name="DB_WIDGET_WIDGETTYPEID_MIN_VALUE" value="1" /> 
		<property name="DB_WIDGET_WIDGETTYPEID_MAX_VALUE" value="2147483647" /> 
		<property name="DB_WIDGET_TITLE_MIN_LENGTH" value="0" /> 
		<property name="DB_WIDGET_TITLE_MAX_LENGTH" value="50" /> 
		<property name="DB_WIDGET_DESCRIPTION_MIN_LENGTH" value="0" /> 
		<property name="DB_WIDGET_DESCRIPTION_MAX_LENGTH" value="255" /> 
		<property name="DB_WIDGET_COST_MIN_VALUE" value="0" /> 
		<property name="DB_WIDGET_COST_MAX_VALUE" value="2147483647" /> 

	</properties>


	
	<listeners>

		
		<listener name="widgetListener" type="MyCmsProject.View.WidgetListener">
			<invoker type="GiGi.framework.invokers.CFCInvoker_Event" />
		</listener>

	</listeners>


	
	<event-handlers>

		
		
		

		
		<event-handler event="widget.showWidgets" access="public">
			<event-bean name="widgetListBean" type="MyCmsProject.View.ListBean" />
			<notify listener="widgetListener" method="doShowWidgets" />
			<view-page name="widget-Widgets" contentKey="view.layout.content" />
		</event-handler>

		
		<event-handler event="widget.showWidget" access="public">
			<event-bean name="widgetBean" type="MyCmsProject.View.WidgetBean" />
			<notify listener="widgetListener" method="doShowWidget" />
			<view-page name="widget.widget" contentKey="view.layout.content" />
		</event-handler>

		
		<event-handler event="widget.updWidget" access="public">
			<event-bean name="widgetBean" type="MyCmsProject.View.WidgetBean" />
			<event-mapping event="success" mapping="widget.showWidgets" />
			<event-mapping event="failure" mapping="widget.showWidget" />
			<notify listener="widgetListener" method="doUpdateWidget" />
		</event-handler>

		
		<event-handler event="widget.delWidget" access="public">
			<event-mapping event="success" mapping="widget.showWidgets" />
			<event-mapping event="failure" mapping="widget.showWidgets" />
			<notify listener="widgetListener" method="doDeleteWidget" />
		</event-handler>

	</event-handlers>


	
	<page-views>

		
		
		

		<page-view name="widget-Widgets" page="/View/WWW/aspx/widgets.aspx" />
		<page-view name="widget.widget" page="/View/WWW/aspx/widget.aspx" />

	</page-views>


</GiGi>

[Aleks Seovic]

Hi Jeff,

Both Front Controller and Page Controller are perfectly valid patterns, and if you prefer Front Controller, or if it works better for your specific scenario, there is no reason why you cannot roll out your own Front Controller-based framework on top of Spring.NET.

The reason I chose to go down the Page Controller route was because I wanted to make move from classic ASP.NET to Spring.Web as simple as possible for developers. While there might be some benefit in implementing Front Controller-based MVC framework, I just didn't think it was significant enough to require Spring.NET users to unlearn what they already know and teach them how to write web apps using different programming model. I still believe it was the right choice, given the amount of positive feedback we've received from the users so far.

That said, there is a chance we might have Front Controller-based web framework in the future. It would make support for different view types much simpler, and it would be a better fit for certain types of applications. For now however, I believe the features that we added to Spring.Web whose primary goal is to close the gaps in ASP.NET and to enable Spring programming model, represent a significant improvement and provide enough value over classic ASP.NET, and allow users to write ASP.NET-based web applications in a much simpler, cleaner and richer way.

As for your example, there are many ways to implement Front Controller in ASP.NET, and your HttpModule-based approach is definitely one of the alternatives. I personally prefer to use handler factory as dispatcher, but again, that doesn't mean that there is anything wrong with your apporach -- if it solves your problem, there is no reason why you should change it.

Regards,

Aleks