三层架构中DAL层有什么用，不是画蛇添足吗？

Question

一般来说bll没什么事情要做，但实际上是开发中弱化了bll的过程，bll本身的意思就是业务逻辑层，是封装业务逻辑的，但实际开发中我们经常做的一件事情就是把业务直接是在UI层做掉了，结果就是导致BLL层就是一个简单的调用DAL层

Answer 1

bll 在简单系统中确实显得多余 一旦系统复杂起来，对程序的可读性及可维护性，就会大大增加的

Answer 2

楼主看看这个帖子吧：
http://bbs.csdn.net/topics/390710763?page=1#post-396770239

Answer 3

DAL说明了就是去除了逻辑思维,单纯的 查询\添加\删除\修改BLL带上了逻辑思维,对DAL进行扩展和重写GetInforBYID(){dal.Select}
GetInforBYName(){dal.Select}
其实都是调用DAL的同一个接口

Answer 4

优点
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期维护的时候，极大地降低了维护成本和维护时间楼主看看这个帖子,通俗易懂
http://blog.csdn.net/hanxuemin12345/article/details/8544957

Answer 5

谢谢，那ID和Name参数不同，dal.select该怎么处理呢，是要重载两个方法吗？

Answer 6

GetInforBYID(int id){
   string cond=" WHere id=@id"
   ....
   paran.id=id
   return  dal.select(cond,paran);
}GetInforBYName(string name){
   string cond=" WHere name=@name"
   ....
   paran.name=name
   return  dal.select(cond,paran);
}
谢谢，那ID和Name参数不同，dal.select该怎么处理呢，是要重载两个方法吗？

Answer 7

谢谢，那ID和Name参数不同，dal.select该怎么处理呢，是要重载两个方法吗？你说的我恍然大悟，这样DAL就只剩几个方法了，但这样需要bll帮忙拼接SQL的，与bll直接写sql有差吗？

Answer 8

谢谢，那ID和Name参数不同，dal.select该怎么处理呢，是要重载两个方法吗？你说的我恍然大悟，这样DAL就只剩几个方法了，但这样需要bll帮忙拼接SQL的，与bll直接写sql有差吗？对于小项目来说没有区别，但对于大型开发，和团队开发来说区别很大，BLL和DAL分不同的人来写的时候,往往一开始只是定义了接口(只有方法名称，没有实质内容),然后开发bll的就遵循给定的接口进行调用开发，另一个人就做接口的实现，如果以后出现问题，bll的问题就去找做bll的人改，dal的问题就去找dal的人处理

Answer 9

谢谢，那ID和Name参数不同，dal.select该怎么处理呢，是要重载两个方法吗？你说的我恍然大悟，这样DAL就只剩几个方法了，但这样需要bll帮忙拼接SQL的，与bll直接写sql有差吗？对于小项目来说没有区别，但对于大型开发，和团队开发来说区别很大，BLL和DAL分不同的人来写的时候,往往一开始只是定义了接口(只有方法名称，没有实质内容),然后开发bll的就遵循给定的接口进行调用开发，另一个人就做接口的实现，如果以后出现问题，bll的问题就去找做bll的人改，dal的问题就去找dal的人处理所以是说bll尽量不要出现sql语句，但一些where条件还是可以的么

Answer 10

谢谢，那ID和Name参数不同，dal.select该怎么处理呢，是要重载两个方法吗？你说的我恍然大悟，这样DAL就只剩几个方法了，但这样需要bll帮忙拼接SQL的，与bll直接写sql有差吗？对于小项目来说没有区别，但对于大型开发，和团队开发来说区别很大，BLL和DAL分不同的人来写的时候,往往一开始只是定义了接口(只有方法名称，没有实质内容),然后开发bll的就遵循给定的接口进行调用开发，另一个人就做接口的实现，如果以后出现问题，bll的问题就去找做bll的人改，dal的问题就去找dal的人处理所以是说bll尽量不要出现sql语句，但一些where条件还是可以的么基本上是这个意思
Dal里，一般是一个类对应一个表的处理方法BLL有可能是一个类操作几个表比如新闻分栏目和内容Dal里面是这个
Dal.栏目
  添加,修改,删除,查询列表，单条查询
Dal.内容
  添加,修改,删除,查询列表，单条查询Bll里可能只用定义新闻就够了新闻
  创建栏目
  修改栏目
  获取栏目信息
  获取栏目列表
  删除栏目
  创建新闻内容
  修改新闻内容
  获取新闻内容
  获取新闻列表
  删除新闻列表

Answer 11

是的，一个bll可能对应多个dal，这个能理解。那如果说sql语句中，Where应该算业务逻辑，所以他由bll提供，那类似的，Top和Order By不也应该由bll来提供吗？我一会有获取日期排序的，一会要获取Id排序的，总不能dal写成两个方法吧，还是要由bll把需要order by的字段当参数传过来，bll需要提供一句sql的大多数东西，为何不直接提供完整的sql语句呢？我的理解是，除了最最最简单的sql语句，稍微有点条件的sql语句都涉及到业务逻辑，那么sql语句就应该由bll来提供。但是bll提供的不一定是sql语句，而是一种协议，他可以是sql语句的形式，也可以是lambda形式或者其他..至于DAL负责的是，解析bll传过来的协议，从而取出相应的数据，映射成实体返回。不知我这样理解是不是错的很离谱？

Answer 12

DAL层是单纯进行数据库访问的层，也就是说在这层里不存在业务逻辑判断，同样UI层也不应该有业务逻辑判断，这些都是BLL层的事情，只是很多人没意识到这一点，结果BLL成了单纯的传声筒，判断都在UI层做了

Answer 13

再写一些复杂的SQL语句的时候！因为涉及到好几个表！所以就老是纠结应该把这个条写到DAL层中的哪个对应的类中。。

Answer 14

如果你需要研究DAL，你会发现不同的数据库系统有不同的API协议。传统的关系数据库好一些，往往通用地支持最基本的sql（sql92？）标准。而nosql各有各的原生查询方法。研究并封装应用程序调用数据库的API，这就是DAL。因此SQLHelper是一个初步的、准确的DAL。DAL作为一种常用的服务工具框架平台，它当然应该脱离开业务逻辑，在你了解了业务逻辑之前就完善它。而至于说那种“一个类对应一个表的处理方法”的DAL，除了越俎代庖地去做一点BLL的事情，混淆了DAL真正应该负责的职责，反过来我们也可以看出这种所谓的DAL的技术含量和灵活性等于零。

Answer 15

其实如果你在DAL层没有什么可做的，你就可以什么都不做，直接调用各种数据库操作框架。其目的就是为了高效率地进行数据库通用操作，而不是把自己弄得繁琐。调用DAL，你未必是在BLL中写sql语句。你可能通过Linq provider写，也可能是调用某种原生的NoSql写程序来操作。关于“BLL和DAL耦合在一起的才比较科学呢”这个说法不准确。实际上你此时根本没有写DAL，你只是写了类似于BLL的代码，其中调用微软的DAL框架。

Answer 16

这说明，你在DAL方面其实没有什么进行什么（与业务逻辑无直接关系的）技术研究，而仅仅不过是越俎代庖地纠结BLL本该做的事情呢！

Answer 17

其实是项目分工的问题，小项目可能直接一层比两层省力，但到了项目臃肿的时候才发挥出DAL和BLL并用的好处吧