在软件体系架构设计中,分层式结构是最多见,也是最重要的1种结构。3层从下至上分别为:数据访问层(DAL)、业务逻辑层(BLL)、表示层(UI)。
表现层(UI):展现给用户的界面,即用户在使用1个系统的时候他的所见所得。
业务逻辑层(BLL):对数据层的操作,对数据业务逻辑处理。
数据访问层(DAL):对http://www.wfuyu.com/db/的操作,数据的增加、删除、修改、查找等。
为何要用3层架构?
解耦!
不是所有的程序都需要使用3层架构,没必要把简单的问题复杂化。
先来讲1下解耦,举例:修电脑
电脑硬盘坏了?我们要做的就是换掉电脑硬盘
内存条坏了?只要换内存条就好
这些部件出现问题,都不会影响别的部件的正常使用,这个就是让他们之间解耦。而和电脑不同的收音机,任何部件坏了,都会影响别的部件,这个体现的就是他们之间的耦合比较高。从这个例子里面就能够看出解耦的好处,在3层中就是用的解耦的思想。
数据访问层:从数据源加载(Select),写入(Insert/Update),删除(Delete)数据。仅限于和数据源打交道,让程序简单明了。
显示层(UI):向用户展现特定业务数据,收集用户的输入信息和操作。
原则:用户至上,统筹简洁。
业务逻辑层(BLL):从DAL中获得数据,以供UI显示用,从UI中获得用户指令和数据,履行业务逻辑、从UI中获得用户指令和数据,通过DAL写入数据源。
UI->BLL->UI:UI提供数据指令到业务逻辑,若自己可以弄定,则直接反馈到UI
UI->BLL->DAL->BLL->DAL:UI提供用户指令和数据,提出要求并搜集1定的数据BLL,BLL处理不了时,要访问数据源,则转给DAL
以登陆为例子,说明3层之间的援用关系:
实体层(entity):定义的用户名和密码。
U层:向对应的文本框中输入账号和密码
B层:判断U层输入的账号和密码是不是存在。
D层:连接http://www.wfuyu.com/db/的语句,查询http://www.wfuyu.com/db/。
他们之间的联系是通过实体传递来进行的,。
DAL所在程序集不援用BLL和UI
BLL需要援用DAL
UI直接援用DAL,可能援用BLL
非常忌讳相互援用,为了不这个问题所有出现了实体层(业务数据模型,里面的数据和http://www.wfuyu.com/db/的有所差异)
DAL只提供基本的数据访问,不包括任何业务相干的逻辑处理。UI只负责显示和收集用户操作,不包括任何的业务相干的逻辑处理,BLL负责处理业务逻辑,通过获得UI传来的操作指令,决定履行业务逻辑,在需要访问数据源的时候直接交给DAL处理。处理完成后,返回必要数据给UI。
表示层(UI)是用户需要的界面,用户有甚么需求都是在这个上面进行的改动,1旦有改动,首先U层向B层发送用户要求的说明,到达B层,B层再将U层的用户要求发送到D层,D层接遭到用户要求的指令后,对它进行处理,发送数据反馈到B层,B层再发给U层,将这1变化反应出来。
举例:
小菜和大鸟吃羊肉串的例子,小菜和大鸟就是用户,服务员为表示层(U层),烤肉师父为业务逻辑层(U层援用B层的方法或参数),老板娘为数据访问层(D层),负责给烤肉师父从库房拿烤串。大鸟点了羊肉串5串(参数),服务员把羊肉串5串(参数传递)传递给烤肉师父(数据要求),烤肉师父再传递给老板娘(对参数进行处理),老板娘得到要求后,拿羊肉串给烤肉师父(数据反馈),烤肉师父将烤好的羊肉串给服务员(数据反馈),服务员再将5串羊肉串给大鸟(U层展现出来),他们之间通过调用来实现联系。
业务逻辑简单,没有真实的数据存储层
抽象出业务逻辑层,当业务复杂到1定程度,当数据存储到相应的存储介质,数据存储脱离开业务逻辑,把业务逻辑脱离开UI单独存在,UI只需要呼唤业务访问层,就能够实现跟用户的交互。
1、开发人员可以只关注全部结构中的其中某1层;
2、可以很容易的用新的实现来替换原有层次的实现;
3、可以下降层与层之间的依赖;
4、有益于标准化;
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期保护的时候,极大地下降了保护本钱和保护时间。
这几点的中心思想就是“高内聚,低耦合”,类之间的耦合越弱,越有益于复用,1个处在弱耦合的类被修改,不会对有关系的类造成波及。
以上是对3层的简单认识,有的地方可能写的不对,欢迎指出!