小孩子就喜欢问什么是爱情,可是大人们也不知道
用户界面表示层(UI)
业务逻辑层(BLL)
数据访问层(DAL)
所谓的三层架构,是小白们最流行讨论的话题,以为自己很专业,其实就是很专业,专业到没有人解释得清楚.
那什么是三层呢?
今天你三层了吗?
我见过很多小白,喜欢在代码中写3个项目文件(或者3个文件夹),命名为MODEL, BLL和DAL,
DAL里是TSQL与SP,
BLL完全只是调用单个DAL方法,例如
CLASS BLL
ShowProducts()
{
DAL.GetProducts();
}
以此类推,
完全是为了三层而三层,并不知道为什么要三层.并不是我给自己儿子起名字叫主席,就可以入主中南海.名字只是个代号.
我不知道这样的BLL是在搞什么.
所谓BLL,它的作用是,,根据用户的某个指令,遵守我们业务所制定的规则,执行流程的作用,
将DAL中所返回的实体进行有机的联系与约束,
然后
或者保存或者展现给用户.
而一个程序,远远不止三层,比如
将结果序列化成json或者xml,(用于ajax或者与webservice通信,或者作为webservice)
依赖注入的IOC容器(用于对象共享与持久化)
即将登上历史舞台的Entity Framework
他们都是抛开业务逻辑,而又不参与TSQL,(Entity Framework是将通用的Entity Sql查询转换为数据库查询的封装)
Entity Sql语句还是要你自己来写,而这个SQL语句集合将成为DAL
还有很多很多游走于各个层之间的框架.他们独立于业务,也不管我们写的是SQL语句性能有多低,它们都只是完成自己的功能.
它们又属于什么层呢?
我们为了解决方案(框架)独立于业务,从而使它可以做为通用方案而进行分层(不是三层),
不要为了三层而三层.
某知名ERP软件开发商,其软件运行的流程为
用户按钮(UI层)--->执行1000~5000行语句的存储过程(数据库操作)---->结果填充至DATASET(他们叫VO)----->展现给客户(UI层)
既然名企都只搞了2层.(当然了,他们是懒,在此点名批评.)
我们为何要对着那些没有严格遵守"三层法律"(或者三层公理)的人一脸不屑的表情呢.
通过接口抽象所实现的弱耦合是每一个基础解决方案(框架或功能集合)所必备的,并非只有层与层之间才有.
先写这么多,,,待续...............
今天,你还在三层吗?
以下是我copy阅读次数最多的关于三层架构的文章(个人不建议效仿)