基于软件测试开发技术.NET的Web应用框架构建模式

基于软件测试开发技术.NET的Web应用框架构建模式 NET网站架构

关键字：.NET Web应用框架

　　本文对应于Web表示模式集群，文章的前半部分重笔墨的描述了MVC模式的架构、设计及其ASP.NET实现，而在更加复杂的系统中，随后提出了Page Controller(页面控制器)和Front Controller(前端控制器)作为MVC实现的补充，最后，简要介绍了Web表示模式集群的另外两个模式：Intercepting Filter(筛选器)和Page Cache(页面缓存)模式。

　　软件开发网

　　“体系结构设计者的第一个作品往往比较简练和干净。他知道自己并不了解正在进行的工作，因此他小心谨慎地设计它。在他设计第一个作品时，会进行多次修饰和润色。这些会留到“下一次”使用……这第二个系统是他曾经设计的最危险的系统……一般趋势是，在设计第二个系统时，将会使用在第一个作品中被小心搁置在一边的所有思路和修饰，从而导致设计过了头。”

　　—Frederick P. Brooks, Jr.发表于1972年的The Mythical Man Month(人月神话)。

　　Web上建立的第一个系统是简单地链接在一起的静态HTML页面，以便在分散的小组之间共享文档。随着用户的使用量增加，可响应用户输入的动态网页日益普遍。早期的动态页面一般是以通用网关接口(CGI)脚本的形式编写的。这些CGI脚本不仅包含用来确定在响应用户输入时应当显示什么内容的业务逻辑，而且还会生成表示HTML。随着对更复杂逻辑需求的增加，对更丰富、更生动的表示形式的需求也随之增加。这种增加了的复杂性给CGI编程模型带来了挑战。

　　不久，基于页面的开发手段(如ASP和JSP)出现了。这些新方法允许开发人员将脚本直接嵌入到HTML面中，从而简化了编程模型。当这些嵌入的脚本应用程序变得更复杂时，开发人员希望在页面级别将业务逻辑与表示逻辑分开。为适应这一要求，随之出现了具有帮助器对象和代码隐藏页面策略的标记库。然后，又出现了提供动态配置站点导航和命令调度程序的精细框架，但所有这一切都是以增加复杂性为代价的。假设现在有大量的Web表示可选方案，如何为您的应用程序选择适当的Web表示设计策略?

　　是否真的有一个设计策略能够适应所有的情况?很不幸，在软件设计中，消除过多的冗余和过度的复杂性是一个竞争性需求，很难能够真正做到两者之间的平衡。您可以从包含嵌入脚本的简单页面开始设计工作，但很快业务逻辑就会不断重复出现在各个文件中，从而导致系统难以维护和扩展。通过将该逻辑移到一组协作组件中，可以消除冗余，但是这样做会增加解决方案的复杂性。另一方面，您的设计工作可以从设计用来提供标记库、动态配置和命令调度程序的框架入手，可是这样虽然能够消除冗余代码，但它会大大增加系统的复杂性，而这通常是不必要的。

　　而如何考虑各个方面的需求，提出一个最合适我们应用的Web表示策略呢?这需要在复杂解决方案(支持将来可能发生变化的情形)和简单解决方案(满足目前的要求)之间做出抉择，原则上适当增加成本是可取的，而过多增加成本却是不可取的。那么废话少说，我们就从“简单”开始吧。

　　MVC(模型—视图—控制)

　　许多计算机系统的用途都是从数据存储检索数据并将其显示给用户。在用户更改数据之后，系统再将更新内容存储到数据存储中。因为关键的信息流发生在数据存储和用户界面之间，所以您可能倾向于将这两部分绑在一起，以减少编码量并提高应用程序性能。但是，这种看起来自然而然的方法有一些大问题。一个问题是，用户界面的更改往往比数据存储系统的更改频繁得多。将数据和用户界面这两部分耦合在一起带来的另一个问题是，业务应用程序往往会并入远不止数据传输功能的其他业务逻辑。如何让Web应用程序的用户界面功能实现模块化，以便您可以轻松地单独修改各个部分?

　　Model-View-Controller正是这样的模式，它实现功能模块和显示模块的分离，使得应用程序更加可维护，可扩展，可移植和可复用，它最初是Trygve Reenskaug在二十世纪七十年代末为Smalltalk平台开发的框架[Fowler03]，而发展到目前为止，已经形成了一个非常成熟的模式。

原文转自：http://www.ltesting.net