【三层架构】对于三层架构的认识和总结

前言

介绍
表示层UI

业务逻辑层BLL

数据访问层DAL

图示

条件约束

扩展
七层

解释

缺点

小结

前言

随着自己学习的不断深入，接触到了三层架构下的程序设计模式，比起之前把所有的数据结构和资料都丢给一个窗体或者几个模块去做，在逻辑和方法上都体现除了职责单一原则。同时，三层架构下的程序开发也令多人开发模式变得高效起来。现在回头想想，之前自己的那种菜鸟的编程方法如果把代码交给了别人，那简直没谁了……

介绍

那么到底什么是三层结构呢？下面就来一起学习一下。

表示层（UI）

展现给用户的界面，即用户在使用一个系统的时候他的所见所得。依据应用规模的不同，所承受的负荷会有较大的差异，另外客户端的数目，应用的复杂程度都会对其造成一定的影响。

业务逻辑层（BLL）

对数据层的操作和业务的处理。接收用户的指令或者数据输入，提交给应用层做处理，同时负责将业务逻辑层的处理结果显示给用户。相比传统的应用方式，业务层对硬件的资源要求较低。

数据访问层（DAL）

直接操纵数据库，主要是增删改查的功能。存储数据的数据库服务器和处理数据和缓存数据的组件。组件将大量使用的数据放入系统的缓存库，以提高数据访问和处理的效率。（对操作系统的作业调度熟悉的小伙伴们来讲，“预读”和“现用现调”两者之间的速度差别那可是非常巨大的）

图示

条件约束

3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理，所以BLL层有效的减少了单窗体一览全局的处理能力，让代码分工变得非常明确，也便于维护和交流。

所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，三层是指逻辑上的三层。三层体系的应用程序将业务规则、数据访问、合法性校验等工作全部交由中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是与中间层建立连接，再经由中间层与数据库进行交互。

所以，有了这些设计理念的约束，我们才可以在真实的开发中去实现所谓的“三层”划分。但是，“三层”这个概念也只是一个宏观上的划分，在实际的开发过程中，我们经常用到的分层更是远远超过“三层”（当然，这也视情况而定）下面我们再用一个图来说明一下。

扩展

“七层”

解释

其实对于七层而言只是在原来的基础上根据具体需要进行了相应的扩展，但是原则还是没有改变的。

界面外观层：提供与用户交互的界面。

界面规划曾：根据用户指令调用业务接口层相映的接口，并将数据传输给业务逻辑层。

业务接口层：提供给表示层指令接口，并将指令操作返回。

业务规划层：根据用户指令和数据的不同，将该指令划分给不同的构造器处理，并构造出实体。

实体层：抽象出数据库对象，如表实体、视图实体、存储过程实体等。

数据访问层：具体操作数据库，如曾删改查等操作。

数据库层：专指数据库，包括数据库内所有的表、视图、存储过程、触发器等数据库对象。

缺点

凡事都有两面性，这种“冗长”的结构也不例外：

1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。 　　

2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。 　　

3、增加了开发成本。

小结

以我个人的角度来看待这种多层的程序设计，它虽然有一些缺点，但是在“职责单一”“扩展关闭”以及“依赖倒转”等原则上，完美的表达了OOP的思想。对于程序的解耦合也起到了非常大的作用，所以在今后的程序设计中，一定要根据具体的情况运用多层设计模式，从而达到代码复用和便于维护的目的。