三层模式的思考

UI，逻辑，数据三层模式是最为经典的面向大规模数据处理的项目场景的解决方案。

下面是我的看法：

UI层使用逻辑层，而逻辑层使用数据层。

也就是，UI依赖逻辑，逻辑依赖数据。从面向对象角度，数据层位于抽象的顶端。

面向对象的原则，是抽象顶端尽量不要变动，否则依赖他的底层必然需要修改。而底层可以变动，顶层无需更改。

在这种三层模式下，数据层是最不允许变动的。

不过实际项目的后期维护中，我们绝不会无端端为了修改UI而修改UI，而是用户的需求发生了变化，其中变化的主要层次，就是数据层的变化。这种现实下，三层模式是否已经失去意义了？

应该说这种现实，会让三层模式失去很多架构上的优势，但是三层模式有助程序的面向对象化。数据层内部的结构改善后，有两个优点：一、和物理存储分离；二、数据实体局部化，比如教师和学生两个数据实体，只是修改教师部分，也只会影响依赖教师部分的逻辑和UI，而不会影响学生部分。

实施三层模式，有助开发从上至下，从抽象到具体，从数据层到UI层进行，减少开发方向混乱造成的重复修改。

其余补充：

数据层的变动这里说的是数据结构上的变动，而不是存储等细节的变动。因为存储细节是数据层的任务：数据层的任务就是抽象了数据的存储位置，以提供一个统一的数据结构给其他部分使用。从面向对象角度，数据层的变动说的是接口的变动，而不是实现的变动。

三层模式，还有一个普遍的要求是分离UI层和数据层的控制关系，用逻辑层做为交互的桥梁。但是要注意这里说的是控制关系，而不是面向对象语言所谓的依赖关系。UI层对数据层的依赖是天然的，虽然某种意义上可以减少这种直接的依赖，但是没有必要刻意去做这件事。