最近从朋友处得到的演讲用演示文稿。中心是关于“架构设计”，里面提到了架构、业务建模及其设计准则。还配有实例进行说明。

标题：应用系统结构体系概述
页数：31
修复后的文档下载(*.zip 压缩文档)
注意：文稿中所使用动画效果，需要Microsoft Office PowerPoint 2003才能完全支持。

从文档可以看出，该演讲人对于ASP.NET表示层的设计有着很深入的研究。大家可以参考。

为了本文不至于过短，特摘录其中要点及比较有价值的理论：

“架构”的定义
“系统的基本组成结构，具体表现为组件，组件之间的相互关系、组件与运行环境的关系，管理其设计和演变的原则。”

目前Microsoft .NET所倡导的软件分层设计，其目的并非单纯为了进行分布式应用。与以往传统的“三层结构”有着本质的不同。对于Microsoft .NET平台上的应用系统来说，并非一般意义上的客户端－服务器－数据库三层结构可与之相比。这里的“架构”在本质上不同于上述“结构”。架构的提法是建立在应用的系统设计层面，是面向系统分析而言的，是纯软件的，面向编写程序的N层架构。其划分的各个层次均为软件层次。

业务建模不同于数据库设计
业务建模仅仅是定义数据格式(schema)，应用模型并不会与关系数据库里的表一一对应。虽然有些时候二者是类似的。业务模型表现的是逻辑意义上的数据数据定义，比如工程项目开工日期、建筑面积或者建筑公司。而关系数据库的设计准则与数据定义不同。某个业务模型中的对象，其数据持久化到关系数据库时，可能会占用两个或多个表。这需要数据访问层的逻辑来实现。

另外，业务模型的数据变动并不能完全对应于关系数据库的“读写删改”操作。所以进行“读写删改”形式的模型设计是错误的

ASP 3.0 还是 ASP.NET

ASP.NET不是给光会“读写删改”的“程序员”准备的。在团队技术水准不高或者公司实际技术积累不够的情况下，盲目转向.NET只会按照ASP的习惯和思路写ASP.NET。这样虽然可以出产品，但这样的做法是图快的、目光短浅的和不严谨的，当需求更改或者需要对系统进行升级时，将面临一系列不可收拾的局面。与使用ASP 3.0相比，开发成本反而会升高。

ASP.NET是为企业级应用准备的。使用ASP.NET满足其基本的特性，即灵活性、重用性和逻辑分离和集中。

架构既可以很高级，也可以很小巧，完全看项目的需要。但不能因为较少编码上的工作量来筛减系统的灵活性和重用性，或者在设计上花费的精力不足。一个设计良好的系统，进行编码、美术设计以及数据库设计的工作量与系统分析相比是很小的。 一个架构开始可能是不合理的、不科学的或者难以使用的，可以随着项目的增多慢慢达到完美。但架构一定要遵循既定的规范。否则就不能称之为“架构”。