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

http://blog.csdn.net/lishehe/article/details/8497564

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

 基本概念

 

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

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

 初识三层架构……为什么要分层?_第1张图片

 
1、表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。
3、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、查找等。

初识三层架构……为什么要分层?_第2张图片

 

 

为什么要分层?

 

解耦

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

 

复杂问题简单化

 

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

 

便于系统维护与升级

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

 

逻辑复用(代码复用)和劳动成本的减少

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

 

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

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

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

 

代码规范

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

 

方面部署

       将各层开发成组件,开一独立部署(现在还没有接触)。

 

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

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

 

为了管理和维护

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

 

分层注意的问题

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

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

 

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

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


你可能感兴趣的:(初识三层架构……为什么要分层?)