用新一代.NET技术构造N层Web应用

近期，Dan Wahlin在其博客上发表的一篇名为《Building an N-Layer ASP.NET Application with LINQ, Lambdas and Stored Procedures》的文章颇引人注目，该文使用.NET 3.5版本新引入的LINQ、Lambda表达式实现了一个基于Northwind数据库的在线电子商务应用，该文同时也勾起.NET社区对如何设计下一代N层应用的思考和讨论。

该应用被划分为4个层次，除了表现层（Presentation Layer）、业务逻辑层（Business Layer）和数据访问层（Data Access Layer）之外，抽象了一个业务模型层（Model Layer），该层用XSD（XML Schema）定义了与具体数据访问技术无关的业务实体模型，目的是保证无论底层数据访问技术采用LINQ to SQL设计器生成的类型、还是自己组织Lambda表达式或者是直接通过访问存储过程的方式，都可以向上层应用提供模型层定义的标准动态业务实体。该示例应用的逻辑分层如下：

 

说明：

• 展现层采用非异步方式的标准ASP.NET；
• 业务逻辑层基于模型层的对象实体，借助数据访问层ORM之后的关系对象完成与持久层的交互；
• 数据访问层采用LINQ方式，通过访问LINQ设计器生成的关系对象、自定义Lambda表达式生成的关系对象以及借助存储过程生成的关系对象，所有关系对象按照模型层的要求生成匹配的业务实体；

 部署上，业务层、模型层和数据访问层的程序集部署在Web服务器上，供ASP.NET页面的数据绑定服务端控件调用。

从技术使用上，这个示例比较适合作为LINQ的动手实验项目，不过如果再次审视这个项目，似乎更应该称之为“玩具”应用：

• 计算扩展能力相对薄弱，整个体系的计算全部集中在Web服务器部分，而且Business、Model、Data Access三层间没有抽象出代理类型，因此如果不做改造的话无法把相关计算部署到其他进程或服务器内；
• 虽然是一个业务示例，而且也牵涉面向数据的CRUD操作，但欠缺了有关事务性控制的内容；
• 作为一个面向Web的开放式应用，在Model定义部分一直在采用.NET自己的类型定义业务实体，阻滞了其他平台（J2EE、Ruby、PHP…）与之互操作的能力；
• 因为采用标准ASP.NET访问二进制程序集的方式，并没有开放的服务接口，影响外部应用的进一步扩展，以及B2B操作的协同；考虑到Customer表、Country表结构相对简单的特点，如果每个Web操作都需要提交，可能用户体验要逊色些，因此可以考虑增加异步处理能力；
• 还有一个就是如果要扩展为面向实际生产的系统，可能需要增加全程的运行监控、维护和安全控制措施；