当使用了MonoRail后发现自己更偏向于使用Front Controllers模式，虽然这模式下缺少了Asp.net服务控件和基于事件驱动的功能，但是功能职责划分更细致明确；于是在WebForm的基础上实现Front Controller模式；实现后发现Controller始终依赖于Page或HttpContext对象才能进行功能处理，这样Controller除了职责不明确外还导致和Page偶合性太高。为了让Controller不关注Asp.Net相关特性，专注于逻辑的处理于是想出了以下改进方法。
1） 隔离Page和Controller,将Controller的处理信息依赖于接口，接口本身定义并不包含任何Asp.Net相关特别性描述。
2） 建立上下文容器进行接口实例的切入，让开发者不用关心接口信息的来源。
3） 接口成员信息自动绑定。
模式改进后的处理结构图：
当使用者请求页面时，框加会通过PageContext进行相关Controller方法定位操作，当查找到相关方法后自动绑定相关接口实例并传递给相关的方法。页面最终根据接口描述的信息进行输出。
下面通过代码了解Page-IView-Controller的处理关系。
首先定义视图描述接口：
/// <summary>
/// 描述订单查询的处理规则
/// </summary>
public interface IOrderView
{
[Bind]
string CustomerID
{
get;
set;
}
[Bind]
string EmployeeID
{
get;
set;
}
System.Collections.Generic.IList<Orders> Items
{
get;
set;
}
}
相关的Controller行为:
public class Controller
{
[FormMapper("~/FrmOrderView.aspx")]//主要用提供Context的方法定位
public void OrderView(IOrderView orderview)
{
if (orderview.CustomerID != null)
{
//...
}
if (orderview.EmployeeID != null)
{
//...
}
//orderview.Items=find Data
}
}
当Controller处理完成后，页面就可以根据接口信息进行输出.
<% IOrderView view = (IOrderView)this.View;
foreach(Order item in view.Items)
{
%>
<tr>
<td><%=item...... %></td>
<td><%=item...... %></td>
<td><%=item...... %></td>
</tr>
<%} %>
从以上代码可以看到Controller具备处理IOrderView的能力，IOrderView的实例不管是Asp.Net创建还是WinFrom下创建都不会影响Controller处理功能，这样Controller的灵活性就更高。
该模式现在还是在构想阶段，有意见或想法的朋友多提一下。