三层架构(3--tier-application)
什么是三层架构?
三层架构通常是将整个业务应用划分为: UI 界面层 BLL 业务逻辑层,DAL数据访问层,Model 实体层 。区分层次的目的即为"高内聚,低耦合"的思想.
1 表现层(UI) ;通俗是展现给用户的界面,及用户在使用一个系统的时候他的所见所得.
2 业务逻辑层(BLL):针对具体问题操作,也可以说是对数据层的操作,对数据业务逻辑处理
3 数据访问层(DAL) : 该层所做事物直接访问数据库,针对数据库的增,删,改,查等.
为什么要分层?
三层结构主要是使项目结构更清楚,分工明确。有利于后期的为维护和升级。 他未必会提升性能,因为当子程序模块未执行结束时,主程序模块只能处于等待状态。这说明将应用程序划分层次,会带来期执行速度上的一些损失。但从团队开发效率角度上来讲却可以感受到大小不同的效果。
注意:三层不是.NET的专利,也不是专门用在数据库上的技术,提示一种更加普适的架构设计理念。
各层作用?
为什么要应用 业务逻辑层呢
我们假设没有一段登录代码, 则可以这样处理WEB程序,外观层负责数据前台页面的数据, 然后传给中间层,中间层对数据进行处理,比如格式化 ,防止SQL注入等。这样的数据在传给访问层然后与数据进行操作,比如与数据库的用户名和密码匹配等等一些代码。
中间层的用途很多, 比如: 验证用户输入数据,缓存从数据库汇总读取的数据等等,但是, 终结业务层的实际目的是将“数据访问”的最基础的存储逻辑组合起来,形成一种业务规则。 例如: 在一个购物网站中有这样的一个规则: 在该网站第一次购物的用户,系统为其自动注册,这样的业务规则房子啊中间层最合适。
在“数据访问层”中,最好不要出现任何的“业务逻辑”。也就是所,要保证"数据访问"中的函数功能原子性。 即最小性和不可再分。”数据访问层“只管负责存储或读取数据就可以了。
实例
对“三层结构”的深入理解——从一家小餐馆说起
一个“三层结构”的Web应用程序,就好象是一家小餐馆。
n 表 现 层,所有的.aspx页面就好像是这家餐馆的菜谱。
n 中间业务层,就像是餐馆的服务生。
n 数据访问层,就像是餐馆的大厨师傅。
n 而我们这些网站浏览者,就是去餐馆吃饭的吃客了……
我们去一家餐馆吃饭,首先得看他们的菜谱,然后唤来服务生,告诉他我们想要吃的菜肴。服务生记下来以后,便会马上去通知大厨师傅要烹制这些菜。大厨师傅收到通知后,马上起火烧菜。过了不久,服务生便把一道一道香喷喷的、热气腾腾的美味端到我们的桌位上——
而我们访问一个基于asp.net技术的网站的时候,首先打开的是一个aspx页面。这个aspx页面的后台程序会去调用中间业务层的相应函数来获取结果。中间业务层又会去调用数据访问层的相应函数来获取结果。
对比一下示意图:
从示意图看,这两个过程是否非常相似呢?
不同的地方只是在于,去餐馆吃饭,需要吃客自己唤来服务生。而访问一个asp.net网站,菜单可以代替吃客唤来服务生。在最后的返回结果上,把结果返回给aspx页面,也就是等于把结果返回给浏览者了。
面向对象与实际的结合
我们知道建立桥需要砖块,应该是先准备好砖再来建造桥,不过为了讲解上的连贯。我们先建立桥,建造的过程中需要用到砖块在做。
U层其实就是桥,C层就是砖块,D层是原料(石头,沙子),这里说为什么U层要引用,依赖D层(而不是U层对C,C对D的层次),因为桥除了需要砖头,其实也需要石头和沙子。
实体图为下图
规则
三层结构的设计不是说把项目分层DAL,BLL,WebUI 三个模块就叫做三层了,下面几个问题是项目里面存在的问题
1 Uilayer 里面只有少量(或者没有) SQL语句或者存储过程调用,并且这些语句保证不会修改数据?
2 如果把UILayer 拿掉,你的项目还能在Interface/API的层次上提供所有功能么?
3 你的DAL 可以一直到其他类似的项目么?
4 三个模块,可以分别运行于不同的服务器码?
如果不是所有的答案都是YES,那么项目还不能算是严格意义的三层程序,三层程序有一些需要约定的规则:
1 最关键的.UI层只能最为严格外壳,不能包含任何的BizLogic的处理过程
2 设计时应该从BLLc出发,BLL层在API上应该事先所有BIzLogic,一面向对象的方式
3 不管数据是一个简单的SQLHerper 也好,还是带有Mapping 过的Classes也好,应该在一定抽象程度上做到与系统无关.
4 不管使用COM+(Enterprise Server),还是remoting,还是WEBService之类的远程对象技术,不管部署时候是不是真的分别部署到不同的服务器上,最起码在设计时候要这样的考虑.更好的.还得考虑多台服务器通过负载均衡作集群.
续篇为三层的详细讲解之实体类 与MVC