初识三层架构……为什么要分层？

随着对三层分层设计的学习（网上搜集资料、小demo的实现）,对分层逐步有个一定的了解,起码别人问起来不会像以前那样,啥也不知道要好的多啦,继续积累ing,下面是自己学习的一些学习笔记

基本概念

三层架构通常意义上的三层是：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

三层不是一定得分三层,我们可以根据项目的大小、复杂程度来多分一点层次也是不可厚非的，三层、四层、五层等要根据实际项目来抉择。

1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。

3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。

为什么要分层？

解耦

上一层依赖于下一层，如果测试下一层没有问题，那么问题就只有可能发现在本层了，便于发现和改正BUG。体现了“高内聚，低耦合”的思想。

复杂问题简单化

各个层次分工明确，将一个复杂问题简单拆分了。

便于系统维护与升级

各层间通过接口解耦，接口与实现分离，从而可以非常简单的替换掉实现，或者实际实现等。

逻辑复用（代码复用）和劳动成本的减少

例如我们现在常用的是SQL数据库，如果我们要变为Orcel数据库的话，只要数据访问层接口不变，我们可以很轻松的实现对不同数据库的实现。

团队合作开发，提高我们的工作效率

只要各层的接口在开发前规定好，那么各层开一独立开发，进行维护等等。

我们以前不分层的话，团队中每个人都需要从业务的需要分析到具体实现都要独自完成，这样的敝处：项目开发过程中对每个人的技术能力要求很高，设计的面也很广，有时也增加了开发人员的压力，最后的代码的测试、维护等等工作都会增加很多麻烦，但是多层次开发是可以解决这些问题的，分工合作、规范代码，我们可以分为需求人员、界面设计人员、代码编码人员、数据库设计人员，分工明确，都各负其职的负责好自己的任务就好，应为都流出了接口，到时之间实现不同接口的实现即可，对于人员的分配，技术强点的可以负责重要的部门的开发工作，对于简单的工作（重复性）安排新手来完成，大大的提高了我们的开发效率。

代码规范

对于每次的代码规范我们都实现制定好，制定好固定的语言开发的风格。

方面部署

将各层开发成组件，开一独立部署（现在还没有接触）。

代码的复用和劳动成本的减少

分层的根本在于代码的复用和劳动成本的减少。分层的最理想化的结果是实现层与层之间的互不依赖的内部实现，所谓的即插即用！

为了管理和维护

使软件开发有条理有秩序，一目了然，让非IT人员也能看得懂软件的框架。

分层注意的问题

更加注意的问题是：分层不是分的越多越好，过多的分层限制了开发人员与客户对系统的理解能力，限制了客户与开发人员的交流。并且会在性能、复杂性等难度上带来不良影响（并非全是），分层越多的话，可靠性有时也是不稳定；项目开发中实在是要具体分析，盲目套用耦合不降反升，效率不高反低，维护不便反繁。

分层不是目的，是软件发展的产物和毕竟之路。层化是把软件横向切了几刀，模块化是把软件纵向切了几刀。

分层最大的好处就是分布式系统。但是一般的大中型项目是没有必要分层的。

我们也要时刻谨记：不能盲目分层，不应分层而分层不应模式而模式。这是很重要的。不然只能增加开发的负担（在今后的实践中更好的体会）。