学完了设计模式和C#,对面向对象有了一定的了解,面向对象的三大特性:封装、继承、多态,为了达到软件可复用,可维护的目的,我们提出来“高内聚低耦合”作为评价软件设计好坏的标准,而接触了三层的知识,对于‘解耦’有了一点点的认识,三层比两层多加了一层,增加了业务逻辑层BLL(Business Logic Layer),从而使得一方对另一方的依赖减小.使得一方的变化不至于引起另一方剧烈变化。
"计算机科学是这样一门科学,它相信所有问题都可以通过多一个间接层来解决." --Dennis DeBruler
就像岳云鹏的《五环之歌》中的唱的那样,啊-- 五环,你比四环多一环~~,提到三层,它比两层多一层~~, 三层是在两层架构的基础上发展起来的,两层架构中用户端直接访问数据层,增加了系统的危险性,而且用户端的职责比较多,既要负责界面,还要负责业务逻辑、访问等内容,如果进行修改的话,就要牵一发而动全身,相当于回炉重造,不灵活,不适于复用,开发也就没有意义了,而三层就很好的优化这一问题,降低了层与层之间的依赖,用户端只能通过逻辑层访问数据层,比较安全,而且变动也不会引起其它层相应的变化,任何一层的变化都不会影响到另外一层,容易维护,两个字:解耦。下面用一张图来说明:
我的理解:两层架构——我自己做西红柿炒鸡蛋:我作为客户,想要吃东西的时候就要想吃什么——西红柿炒鸡蛋?红烧茄子?酸辣土豆丝……(菜谱:界面);然后需要想怎么做(业务逻辑);最后要购买食材(数据访问);这一连串工作都是由我自己去菜市场再完成,如果我临时有事,就不能吃上饭了
三层架构——我要到饭店去吃西红柿炒鸡蛋:服务员拿来菜单(用户界面);点完菜服务员告诉厨师要做饭(业务逻辑);厨师告诉采购人员去菜市场买菜(数据访问),如果服务员、厨师、采购员任何一人有事,都可以更换,我都能吃饭
当业务复杂到一定程度后,当数据存储到一个独立介质后,要使用三层,把数据访问脱离开业务单独存在,把业务脱离开界面单独存在,界面层只需要呼叫数据访问层实现与用户的交互。
通常意义上的三层架构就是将整个业务应用划分为:表现层(Presentation layer)、业务逻辑层(Business Logic Layer)、数据访问层(Data access layer)。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或称为领域层)、表示层。
显示层UI( UserInterface),也叫用户接口: 向用户展现特定业务数据 ;采集用户的输入信息和操作,简单来讲就是我们平时见到的界面
业务逻辑层BLL(BusinessLogicLayer): 从DAL中获取数据,以供UI显示用;从UI中获取用户指令和数据,执行业务逻辑;从UI中获取用户指令和数据,通过DAL写入数据源
数据访问层DAL(DataAccessLayer):数据访问对象的具体操作
UI->BLL->DAL
说明: DAL所在程序集不引用BLL和UI;BLL需要引用DAL;UI直接引用BLL,可能会间接引用DAL;三层中禁忌相互引用
三个层次,职责分明
说明:DAL只提供基本的数据访问,不包含任何业务相关的逻辑处理
UI只负责显示和采集用户操作,不包含任何的业务相关的逻辑处理(拿来主义)
BLL负责处理业务逻辑,通过获取UI传来的操作指令,决定执行业务逻辑,在需要访问数据源的时候直接交给DAL处理,处理完成后,返回必要数据给UI。
数据模型(Model)/业务实体(Entity): 用来封装数据,实现三层之间数据的顺畅流转,传输数据,独立于三层数据;其他程序集会引用Model,Model不知道谁去调用它。一般用于映射数据库的数据表或视图,用以描述业务中客观存在的对象。Model分离出来是为了更好地解耦,为了更好地发挥分层的作用,更好地进行复用和扩展,增强灵活性。
一张图来说明:
优点: ① 开发人员可以只关注整个结构中的其中某一层;
②可以很容易的用新的实现来替换原有层次的实现;
③可以降低层与层之间的依赖;
④有利于标准化;
⑤有利于各层逻辑的复用。
缺点: ①降低了系统的性能(中间层访问);
②有时会导致级联的修改(自上而下的方向)。
三层就是为了达到解耦合的目的,各层次职责分明,各司其职,而数据模型是用来进行三层之间的数据沟通,是面向对象的体现,当发生变化时不至于全部都要改,更加灵活,易于复用和维护。
初次接触三层,只是理论上的东西,不是很理解,通过敲例子去深入了解,如有不完善之处,敬请指出!