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

  • 王翔

2008 年 2 月 26 日

话题:.NET架构语言 & 开发

近期,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 操作都需要提交,可能用户体验要逊色些,因此可以考虑增加异步处理能力;
  • 还有一个就是如果要扩展为面向实际生产的系统,可能需要增加全程的运行监控、维护和安全控制措施;

.NET架构语言 & 开发