62,247
社区成员
发帖
与我相关
我的任务
分享三层架构中DAL层有什么用，不是画蛇添足吗？
初学不久，看了好多三层的文章，基本上讲的都是DAL里放SQL语句，然后针对SQL语句一个一个写方法调用DbHelper，给BLL调用。这种做法是为什么呢？BLL传一个SQL语句当参数就能解决的事，还要单独写成方法来调用，结果每个DAL都一大堆方法，BLL又只是做个判断然后return dal而已。
DbHelper不就是一个DAL层吗，我怎么觉得MVC那种把BLL和DAL耦合在一起的才比较科学呢，代码量也少很多，三层架构中BLL,DAL分开到底有什么好处呢？有没有好例子可以说明下，越看越迷惑了。
DbHelper不就是一个DAL层吗，我怎么觉得MVC那种把BLL和DAL耦合在一起的才比较科学呢，代码量也少很多，三层架构中BLL,DAL分开到底有什么好处呢？有没有好例子可以说明下，越看越迷惑了。
...全文
请发表友善的回复…
发表回复
seplek 2015-02-03
- 打赏
- 举报
这篇很有帮助，很好的讨论
Ptrtoptr 2014-02-22
- 打赏
- 举报
你的困惑刚刚被解开的时候,正是你陷入另一个困惑的时候.三层框架我看过视频,动手做过,最终比对过.不是看一两个贴子就觉悟了.怎么说吗,我在小公司,做不了什么大项目,在这种情况下,过度设计反而适得其反
Coffcer 2014-02-22
- 打赏
- 举报
我认为9楼，15楼，19楼，20楼已经很好的解决了我的困惑，现在对三层有了新的认识，不像以前只是繁琐重复的调用，我不敢说我现在的想法是对的，但我敢说比网上很多三层做法的示例要科学。
你如果还和我1楼时想的一样，建议你多多琢磨下这张帖子上面的回复，我认为很有帮助。
Delta 2014-02-22
- 打赏
- 举报
来学习了。高人
以专业开发人员为伍 2014-02-22
- 打赏
- 举报
这说明，你在DAL方面其实没有什么进行什么（与业务逻辑无直接关系的）技术研究，而仅仅不过是越俎代庖地纠结BLL本该做的事情呢！
以专业开发人员为伍 2014-02-22
- 打赏
- 举报
其实如果你在DAL层没有什么可做的，你就可以什么都不做，直接调用各种数据库操作框架。其目的就是为了高效率地进行数据库通用操作，而不是把自己弄得繁琐。
调用DAL，你未必是在BLL中写sql语句。你可能通过Linq provider写，也可能是调用某种原生的NoSql写程序来操作。
关于“BLL和DAL耦合在一起的才比较科学呢”这个说法不准确。实际上你此时根本没有写DAL，你只是写了类似于BLL的代码，其中调用微软的DAL框架。
以专业开发人员为伍 2014-02-22
- 打赏
- 举报
如果你需要研究DAL，你会发现不同的数据库系统有不同的API协议。传统的关系数据库好一些，往往通用地支持最基本的sql（sql92？）标准。而nosql各有各的原生查询方法。
研究并封装应用程序调用数据库的API，这就是DAL。因此SQLHelper是一个初步的、准确的DAL。
DAL作为一种常用的服务工具框架平台，它当然应该脱离开业务逻辑，在你了解了业务逻辑之前就完善它。
而至于说那种“一个类对应一个表的处理方法”的DAL，除了越俎代庖地去做一点BLL的事情，混淆了DAL真正应该负责的职责，反过来我们也可以看出这种所谓的DAL的技术含量和灵活性等于零。
Ptrtoptr 2014-02-22
- 打赏
- 举报
我操,我和你有同感!
renyiqiu 2014-02-22
- 打赏
- 举报
其实是项目分工的问题，小项目可能直接一层比两层省力，但到了项目臃肿的时候才发挥出DAL和BLL并用的好处吧
苏轩axy 2014-02-22
- 打赏
- 举报
来学习了了！！！
gnimgnot 2014-02-21
- 打赏
- 举报
有两种可能：
1，你的数据层做了超越职责的事
2，你的UI层做了超越职责的事
直面人生 2014-02-21
- 打赏
- 举报
优点
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
6、结构更加的明确
7、在后期维护的时候，极大地降低了维护成本和维护时间
楼主看看这个帖子,通俗易懂
http://blog.csdn.net/hanxuemin12345/article/details/8544957
直面人生 2014-02-21
- 打赏
- 举报
高内聚,低耦合
为了以后程序的改动更加方便
md5e 2014-02-21
- 打赏
- 举报
DAL说明了就是去除了逻辑思维,单纯的 查询\添加\删除\修改
BLL带上了逻辑思维,对DAL进行扩展和重写
GetInforBYID(){dal.Select}
GetInforBYName(){dal.Select}
其实都是调用DAL的同一个接口
走出一条新道路 2014-02-21
- 打赏
- 举报
菜菜的菜菜 2014-02-21
- 打赏
- 举报
再写一些复杂的SQL语句的时候！因为涉及到好几个表！所以就老是纠结应该把这个条写到DAL层中的哪个对应的类中。。。。。
skywalker22 2014-02-21
- 打赏
- 举报
DAL层是单纯进行数据库访问的层，也就是说在这层里不存在业务逻辑判断，同样UI层也不应该有业务逻辑判断，这些都是BLL层的事情，只是很多人没意识到这一点，结果BLL成了单纯的传声筒，判断都在UI层做了
Coffcer 2014-02-21
- 打赏
- 举报
是的，一个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传过来的协议，从而取出相应的数据，映射成实体返回。
不知我这样理解是不是错的很离谱？
md5e 2014-02-21
- 打赏
- 举报
谢谢，那ID和Name参数不同，dal.select该怎么处理呢，是要重载两个方法吗？[/quote][/quote]
你说的我恍然大悟，这样DAL就只剩几个方法了，但这样需要bll帮忙拼接SQL的，与bll直接写sql有差吗？[/quote]
对于小项目来说没有区别，但对于大型开发，和团队开发来说区别很大，BLL和DAL分不同的人来写的时候,往往一开始只是定义了接口(只有方法名称，没有实质内容),然后开发bll的就遵循给定的接口进行调用开发，另一个人就做接口的实现，如果以后出现问题，bll的问题就去找做bll的人改，dal的问题就去找dal的人处理[/quote]
所以是说bll尽量不要出现sql语句，但一些where条件还是可以的么[/quote]
基本上是这个意思
Dal里，一般是一个类对应一个表的处理方法
BLL有可能是一个类操作几个表
比如新闻分栏目和内容
Dal里面是这个
Dal.栏目
添加,修改,删除,查询列表，单条查询
Dal.内容
添加,修改,删除,查询列表，单条查询
Bll里可能只用定义新闻就够了
新闻
创建栏目
修改栏目
获取栏目信息
获取栏目列表
删除栏目
创建新闻内容
修改新闻内容
获取新闻内容
获取新闻列表
删除新闻列表
Coffcer 2014-02-21
- 打赏
- 举报
谢谢，那ID和Name参数不同，dal.select该怎么处理呢，是要重载两个方法吗？[/quote][/quote]
你说的我恍然大悟，这样DAL就只剩几个方法了，但这样需要bll帮忙拼接SQL的，与bll直接写sql有差吗？[/quote]
对于小项目来说没有区别，但对于大型开发，和团队开发来说区别很大，BLL和DAL分不同的人来写的时候,往往一开始只是定义了接口(只有方法名称，没有实质内容),然后开发bll的就遵循给定的接口进行调用开发，另一个人就做接口的实现，如果以后出现问题，bll的问题就去找做bll的人改，dal的问题就去找dal的人处理[/quote]
所以是说bll尽量不要出现sql语句，但一些where条件还是可以的么
加载更多回复（8）
