对三层架构的理解he吐槽

一提到三层架构，很多程序员都能张口就能说出表示层（也有叫UI层、展示层）、业务逻辑层、数据访问层，但是真正在程序实现和具体的设计的时候并不是死板的就这么三层。这三层只是在宏观上分为这么三层，其实一个好的架构是有不同层次来构成的，也非绝对的三层。那么什么才是好的架构呢，很多业内人士和专家也给予了具体的解释和分析，但我想说任何事情没有一成不变的，架构的设计也是需要具体情况具体对待，不能按部就班，生搬硬套。
 首先了解分层的目的和意义在那里，这是很重要的，也就是说我们为什么要分层，有了这个目标，在设计的时候就按照这个目标去设计，只要达到了这个设计的目标，满足需要，就是一个好的架构。那么，三层的目的也意义在那里呢：

第一，对于大型项目来说，分工协作是很重要的，所以考虑到这方面的因素，需要把责任明细化、共同开发，一来这样可以提高效率，二来也是发挥员工其所长；比如，擅长前端的（jquery、CSS、Html）的员工就关注于表示层，而不用关心具体的数据操作；而擅长梳理业务的人，可以把他们定位在业务层上处理数据流向和输入输出。

第二，从面向对象的设计上来讲，就是降低偶尔性和依赖性，我不建议业务层直接去New数据访问层的某一个类来调用，而是应该依赖于接口，而不是一个具体的类，这样就降低了关注点，这点用到了几个设计模式，比如工厂模式、依赖注入等，就是为了实现关注点分离点，使得功能专一的对象封装起来，对于外界的类不需要关心这个类的具体实现，所以一般都会把这些接口定义为一层。而且依赖于接口在业务处理上来说，也十分方便，首先定义接口，也就是具体的操作规范，即便没有具体的实现，各层之间也可以并行开发。

第三，便于维护与扩展，维护修改代码方便，层次清晰嘛；扩展呢，添加功能方便，也使程序的可读性提高，但是不要忘了在定义一个类的时候的单一制原则，和开发封闭原则。再举个例子来讲，将来业务发展了，数据量也会增加，可能公司决策有原来的Access数据库改为MySql或SqlServer，那么这应该是数据访问层的变更，而不应该影响到业务层的变动，应该是把数据库层依赖于数据接口的实现类的变动。如果业务层调用数据访问层的时候是依赖的接口，用工厂模式来实现的话，就可以实现这个目的。

所以，在设计架构的时候前期的分析是很重要的。有的人不理解，干嘛要中间这个业务逻辑层，直接调用数据层不可以吗？其实我想说没有什么是不可以的，只是业务层也有它存在的道理，业务逻辑层，主要负责对数据层的操作，也就是说把一些数据层的操作进行组合。它起到了承上启下的作用，也是对数据层返回来的数据进行二次加工，举些例子:我们假设有一段登录代码，则可以这样处理Web程序，表示层负责接收前台页面的数据，然后传给中间层，中间层对数据进行处理，比如格式化，防SQL注入等等一些，这样的数据再传给数据访问层然后与数据库进行操作，比如与数据库的用户名和密码匹配等等一些代码。还有就是在实际开发中，很多人直接把DA层的接口拷贝到BLL层，连方法名称都不改一下。虽然这样开发快速，但不易于直观的理解，每一层的方法名称的定义都应该有他们的意义所在。还有就是其里面的加工的数据不同，“业务逻辑层”的用途有很多，例如：验证用户输入数据、缓存从数据库中读取的数据等等……但是，“中间业务层”的实际目的是将“数据访问层”的最基础的存储逻辑组合起来，形成一种业务规则。

另外，还有一些公共的方法类，比如缓存、对字符串的处理等，这些东西也算在一个辅助层，一般都是写成静态类和静态方法。所以，没有绝对的三层，只有变通的三层！

为了弥补自己的不足，特在网上也找了一些资料，补充一下：

所谓三层体系结构，是在客户端与数据库之间加入了一个中间层，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交换.开发人员可以将应用的商业逻辑放在中间层应用服务器上，把应用的业务逻辑与用户界面分开。在保证客户端功能的前提下，为用户提供一个简洁的界面。这意味着如果需要修改应用程序代码，只需要对中间层应用服务器进行修改，而不用修改成千上万的客户端应用程序。从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发，简化了应用系统的开发、更新和升级工作。

总的概括为以下几点：
 优点：

1、开发人员可以只关注整个结构中的其中某一层；

2、可以很容易的用新的实现来替换原有层次的实现；

3、可以降低层与层之间的依赖；

4、有利于标准化；

5、利于各层逻辑的复用。

6、结构更加的明确

7、在后期维护的时候，极大地降低了维护成本和维护时间

缺点

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

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

3、增加了开发成本。