三层架构详解.docx

三层架构详解
三层架构详解
三层架构详解
三层架构将数据层接口定义的前提下，理想的分
层式架构，应当是一个支持可抽取、可替代的 “抽屉 ”式架构。正因为这样，业务逻
辑层的设计关于一个支持可扩展的架构尤其重点， 因为它饰演了两个不同的角色。
关于数据接见层而言，它是调用者；关于表示层而言，它倒是被调用者。依靠与被依靠的关系都纠结在业务逻辑层上，怎样实现依靠关系的解耦，则是除了实现业务逻辑以外留给设计师的任务。
数据层
数据接见层：有时也称为是长久层，其功能主假如负责数据库的接见，
能够接见数据库系统、二进制文件、文本文档或是 XML 文档。
简单的说法就是实现对数据表的 Select ， Insert ， Update ， Delete 的操作。
假如要加入 ORM 的元素，那么就会包含对象和数据表之间的 mapping ，以及对
象实体的长久化。
优弊端
长处
、开发人员能够只关注整个构造中的此中某一层；
、能够很简单的用新的实现来替代原有层次的实现；
、能够降低层与层之间的依靠；
三层架构详解
三层架构详解
三层架构详解
优选
三层架构详解
三层架构详解
三层架构详解
、有益于标准化；
、利于各层逻辑的复用。
弊端
、降低了系统的性能。这是不问可知的。假如不采纳分层式构造，好多业务能够直接拜访数据库，以此获得相应的数据，此刻却一定经过中间层来达成。
、有时会致使级联的改正。这类改正特别表此刻自上而下的方向。假如在表示层中需要增加一个功能，为保证其设计切合分层式构造，可能需要在相应的业务逻辑层和数据接见层中都增加相应的代码。
规则
三层构造的程序不是说把项目分红 DAL, BLL, WebUI 三个模块就叫三层了 ,
下边几个问题在你的项目里面：
1. UILayer 里面只有少许 ( 或许没有 )的 SQL 语句或许储存过程调用 , 而且这
些语句保证不会改正数据 ?
假如把 UILayer 拿掉 , 你的项目还可以在 Interface/API 的层次上供给全部功
能吗 ?
3. 你的 DAL 能够移植到其余近似环境的项目吗 ?
三个模块 , 能够分别运转于不同的服务器吗?
假如不是全部答案都为 YES, 那么你的项目还不可以算是严格意义上的三层程序 . 三层程序有一些需要商定恪守的规则：
1.
最重点的 , UI 层只好作为一个外壳
, 不可以包含任何 BizLogic 的办理过程
2.
设计时应当从 BLL 出发 , 而不是 UI 出发 . BLL 层在 API 上应当实现全部 B
izLogic,
以面向对象的方式
不论数据层是一个简单的 SqlHelper