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中下载这个例子. 集中的数据访问提升了代码重用性, 但更重要的是, 通过使用实际容量设置连接可以保证你的应用程序使用连接池.

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

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