回到这篇文章上来，原文在这里，Implementing Model-View-Controller in ASP.NET。我当初在看这部分的时候就相当疑惑，这里所描述的实现能否准确的称为MVC？
先看看大家熟悉得不能再熟悉的MVC的图示：
再看看ESP中对MVC模式的描述（如果感兴趣，可以看看最“正宗”的SmallTalk中MVC模式的描述，点这里）：
It is important to note that both the view and the controller depend on the model. However, the model depends on neither the view nor the controller. This is one the key benefits of the separation. This separation allows the model to be built and tested independent of the visual presentation. The separation between view and controller is secondary in many rich-client applications, and, in fact, many user interface frameworks implement the roles as one object. In Web applications, on the other hand, the separation between view (the browser) and controller (the server-side components handling the HTTP request) is very well defined.
MVC模式有两点非常重要：1、Model完全独立于Controller和View；2、Controller独立于View的实现。上面对MVC的描述的最后一句话的意思是“ASP.NET中通过将View定义到页面文件，将Controller定义到Code-Behind组件中实现了Controller和View的分离”。
我不知道在这里ESP是怎么定义“separation”的含义的，如果Controller是通过“Front Controller”来实现，我还是认可达到了一定的分离度，但是如果Controller是通过“Page Controller”（也就是那个.aspx.cs的Code-Behind的模式）来实现的，我则对于是否真的这就算是“separation”表示怀疑。在这篇文章中，实现MVC就是用的Page Controller的方式。所以，我对于这篇文章中所示范的实现是否真正算是MVC方式表示严重怀疑。
作为一个真正的MVC的系统，Model和Controller因为从View中独立了出来，所以具有非常高的重用性，比如，如果将作为View的页面进行修改，或者干脆把现有的页面文件删除然后再做过新的页面，或者将程序的界面从ASP.NET页面改成一个WinForms程序，甚至改为一个Mobile设备上的程序，Model和Controller仍然是可重用的，就是说，界面背后的数据、流程、状态控制、业务规则都是一样的，所以View的变换决不会影响Model和Controller。
对于一个MVC实现的系统来说，实现上面这一点应该是基本的需求，而且也是MVC的初衷（把View从Model和Controller中解藕出来，View的变化不影响其他部分）。而上文所提到的那样的实现方式，我看不出能够达到MVC所需要达到的要求。
就我所知，现在.NET下真正实现了MVC的框架只有两个：SourceForge上的Maverick和微软的UIPAB，利用它们提供的Framework，可以真正的同时很方便的实现MVC的Application。如果有时间，我希望不久能以UIPAB为基础，写一篇如果实现MVC模式的WebForms程序的文章。