ASP.NET的MVC设计模式

当开发者听到“设计模式”这个词时，他们通常联想到两个场景。一组开发者正在讨论许多创造性意见，正在开会，但是却没有进行编码。另外一组人能制定出正确的计划，保证系统能够开发成功，代码可以重用。

而现实一般都处于两者中间。在为他们的公司设计解决方案的时候，结构设计者和系统设计者应该寻找重复的模式。但是模式只是开发健壮、可重用代码的一个指导。结构设计者不能过多的去设计一个解决方案的结构，因为要定期交货。

过多的设计系统结构的主要受害者是Web应用程序。因为多数Web应用程序是用来浏览数据的，它们设计的目标是数据显示的速度能跟得上数据更新的速度。在很多情况下，建立一个复杂的、多层次的体系结构并不是为了满足用户或者开发者的需要。让我们看看开发.NET Web应用程序的一个简单的例子：

用ASP.NET实现一个经典的设计模式

Smalltalk，最早的一种面向对象的编程语言，给开发者提供了一个快速开发面向对象系统的平台。经典的Model, View, Controller（MVC）设计模式就是从这个研究上发展起来的，并且现在仍在作为一个参考模型使用。Model保存由View显示，由Controller控制的数据。View负责向用户发送输出，Controller负责反应用户的动作并相应地更新Model。

ASP.NET提供了一个很好的实现这种经典设计模式的类似环境。开发者通过在ASPX页面中开发用户接口来实现View。Controller功能在逻辑功能代码（code-behind）文件（Foo.aspx.vb或者Foo.aspx.cs）中实现。

在.NET中实现这种设计提供了一个两层的系统，较经典的ASP结构来说有明显的优点。将用户显示（View）从动作（Controller）中分离出来提高了代码的重用性。将数据（Model）从对其操作的的动作（Controller）分离出来可以让你设计一个与后台存储数据无关的系统。

如果设计正确的话，一个基于MVC设计模式的系统将不会知道、也不会关心提供给Model组件的数据是存储在SQL Server或是Oracle数据库中，还是存储在一组XML文档中。

很多人会说，开发者可以使用ASP页面和COM对象很容易地实现这种模式。但是事实是，我检查的多数系统根本没有使用COM对象，或者只是使用COM对象来访问数据库；他们依然在ASP页面中嵌入脚本来完成商业逻辑。我并不是说MVC模式提倡在ASP页面中不使用脚本。我只是说在ASP页面中的脚本应该只局限于用来支持View功能和Controller功能。

性能和可扩展性

当设计一个基于这种模式的解决方案时，一定要考虑到另外两个问题。首先，这个解决方案的性能如何，我们怎么提升其性能？第二，这个解决方案的可扩展性和可升级性如何，什么地方值得扩展或者打破这种模式？

性能

尽管从Controller和View中访问Model将是独立于具体数据库的，但并不意味着Model自己不能被优化。因为ADO DataSet不关心数据源，通过采用数据库专有的优点不用打破这种模式就可以提高系统性能。例如，相比在你的逻辑功能代码文件（Controller）中使用嵌入的SQL Select语句，我们可以使用存储过程根据给的参数返回想要的值，这种效果会好些。存储过程不仅仅是被数据库中预编译好的，它们还有一个预先确定的执行路径，所以其执行得更快，效率更高。

然而如果你使用存储过程来处理商业逻辑的话，你可能会打破这种模式。这些商业逻辑本应该属于Controller的，允许多个视图使用它们。通常你会用数据库专有的特征来优化系统性能或者强迫引用完整性，但不要用来实现Controller特征。

可扩展性和可升级性

为了能成功地进行升级，一个MVC模式的应用程序不得不工作在Web服务器群下。只要你设计你的应用程序为无状态的或者在View和用户间维持状态（ASP.NET缺省为开发这种应用程序），你就能通过简单地将你的ASPX页面和逻辑功能文件复制到一个服务器群的多个IIS服务器上，全都指向同一个数据库服务器。

当实现这种模式时，我发现将逻辑Controller层分离为两个物理层很有用。相比在Controller层中在多个方法中复制使用同样的数据访问，我更乐意将所有的代码合并在一个单独的数据访问对象中，由它来完成该应用程序所有的数据访问。微软提供了一个比较大的例子，就是将数据访问应用模块全部合并到一个数据访问层中，你可以从MSDN中下载这个例子。集中的数据访问提升了代码重用性，但更重要的是，通过使用实际容量设置连接可以保证你的应用程序使用连接池。

以更快的速度开发更好的软件

使用设计模式能帮助你建立更可靠、更易维护的软件。当给你的客户设计系统结构时，你首先应该考虑建立基于著名设计模式的应用程序，然后再根据需要和性能要求来扩展这些设计模式。