近期，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 操作都需要提交，可能用户体验要逊色些，因此可以考虑增加异步处理能力；
- 还有一个就是如果要扩展为面向实际生产的系统，可能需要增加全程的运行监控、维护和安全控制措施；
暂无签名
中国开发者画像洞察报告 2022
本次报告为你深度解读开发者人群背景，分析开发者群体面临的挑战，洞察开发者人群特征，预测开发者生态发展...
Kata 容器及其在蚂蚁集团的落地实践
淘系前台业务秒交付研发模式的革新探索
数字化转型对基础设施的新要求
评论