CSLA.NET学习笔记：5层分布式架构

好的逻辑分层构架的好处：

• 逻辑的组织代码
• 更好的代码重用
• 更易于维护
• 更好的团队开发体验
• 更高的代码清晰度

合适的物理分层的好处：

• 性能
• 可伸缩性
• 安全性
• 容错性

1. 界面层

界面技术的种类越来越多，并且每种技术都会带来一些新的相对不兼容的技术，你必须为适应他它们而做一些工作。显然不可能创建一个完全概括出界面概念的编程框架。因此，架构或者框架仅仅支持创建各种界面，而不是自动创建。我们应该专注于简化架构中的其他层，在那里使用的技术更加稳定。

2. 界面控制层

决定用户应该看到什么，对路径的导航，以及如何解释用户输入。

在WPF或者WINDOWS、WEB窗体的应用程序中，这都是窗体后台的代码；在ASP.NET MVC应用程序中，视图和控制器都是界面控制层的组成部分。HTML、JAVASCRIPT以及其他视图生成的内容组成了界面层；最后，业务层是模型。

3. 业务层

业务逻辑层包括所有的业务规则，数据验证、控制、处理以及对应用程序的授权等。微软的MSDN上是这样对其定义的：业务逻辑层组合了验证输入框、登录验证、数据库查询、安全策略以及构成企业完成业务的方法的算法转换。

需要再次强调的是，在实现运行在浏览器或者其他外部客户端的验证逻辑的时候，不能信任客户端的代码。你必须将运行在你的控制之下的业务层中的逻辑视为唯一真正的验证逻辑。

业务逻辑必须存在于与界面代码分离的层中。虽然你可能会选择在你的界面控制代码中复制其中的逻辑，来提供丰富的用户体验，但是业务层必须实现所有的业务逻辑，因为它是唯一的集中控制和可维护的点。

可以将一个逻辑层部署在多个物理层中。

4. 数据访问层

数据访问代码与数据存储和管理层进行交互，来查询、插入、更新和删除信息。数据访问层并不真正管理或存储数据，它只是提供业务逻辑与数据库之间的接口。

数据访问层之所以有其自己的逻辑层，原因和界面和界面控制层分离的原因是一样的。

逻辑上将数据访问层定义为单独的一层会迫使业务逻辑和任何与数据库（或者任何其它数据源）的交互分离开。

数据访问机制通常是作为一系列服务实现的：每个服务都是一个过程，业务逻辑调用它来取得、插入、更新或删除数据。尽管这些服务经常使用对象来构建，但重要的是要知道事实上一个有效的数据访问层的设计本来就是过程化的。试图强迫为关系数据库访问做面向对象的设计往往会导致复杂度的增加或者性能的降低。我想最好的办法是将数据访问实现为一系列的方法，但是将这些方法封装到对象里来保证它们被逻辑地进行组织。

数据访问层的另一个常见的角色是提供面向对象的业务逻辑和数据仓库中的关系型数据之间的映射。好的面向对象模型与好的关系型数据库模型几乎完全不同。对象经常包含来自于多个表的数据，或者甚至来自于多个数据库的数据；或者相反的，模型中的多个对象只代表一个单独的表。从关系型模型的表中取得数据到面向对象模型的过程叫做对象－关系映射 ORM。

5. 数据存储和管理层

这层的关键在于它处理数据物理上的创建、取得、更新和删除，数据存储和管理层在数据库上下文、或者一系列文件中，真正实现这些操作。