当开发者听到“设计模式”这个词时，他们通常联想到两个场景。一组开发者正在讨论许多创造性意见，正在开会，但是却没有进行编码。另外一组人能制定出正确的计划，保证系统能够开发成功，代码可以重用。
而现实一般都处于两者中间。在为他们的公司设计解决方案的时候，结构设计者和系统设计者应该寻找重复的模式。但是模式只是开发健壮、可重用代码的一个指导。结构设计者不能过多的去设计一个解决方案的结构，因为要定期交货。
过多的设计系统结构的主要受害者是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功能。