【讨论】存储过程,SQL语句写在DAL层还是写在BLL层灵活弹性？
0
最佳答案
0
从DAL和BLL的名字就可以做出判断了，SQL语句是跟数据访问相关，还是和业务逻辑相关？
在BLL中感觉无法重用DAL的方法，说明DAL的方法封装得不够好。DAL中的语句不能写死，否则一点灵活性都没有了，SQL语句的参数之类的应该是可以作为方法的参数传入的吧？再说，如果你使用存储过程的话，那就更不能用BLL去封装了。
总之，与数据库打交道的一切东西，都应该在DAL中，BLL只负责业务逻辑。
收获园豆：65
同意，所谓的灵活弹性，其实是业务逻辑的变化，但是无论如何将数据访问和业务逻辑混在一起不是太好
同意，我也明白，我就是用DAL写语句或 存储过程 ，但是有时候会碰到存储过程在DAL层写好了或SQL语句写好了，结果在WEB,BLL层再有一个要调用DAL的时候却不能再重用了，那如何个灵活法了？
@时空印记:这时候就是因为DAL没有封装好，导致不够灵活。如果修改DAL接口导致的改动过大，那就再增加一个DAL方法。
其他回答(12)
0
一般来说要放在DAL层，这样的话有助于各层的分离，对于维护来说可能会更好。
0
DAL
0
DAL
0
看来不用讨论了。大家一致DAL
0
存储过程本质上就是业务逻辑，我的极端想法从来都是如果用存储过程，那就别三层架构了，业务逻辑又在数据库，又在bll，中间夹个dal算什么事呀。
要我做，我就是dal对每个实体实现四个方法，分别是增删改查，查什么都是用参数实现，现在不是表达式也可以当参数了么。存储过程扔的远远的，数据库么做好存储就行了
收获园豆：5
0
我随便说说：
1。DAL这东西，定完了，基本上就是对表的基本操作，正常情况下死活都不应该改！写的烂的除外!
2。根据第一条，经常变来变去的自定义SQL就不适合放在DAL
3。在逻辑层里，自定义的SQL应该有规律的存放。
例：
Module项目里
User（文件夹）逻辑控制下有一个:
UserCustomSQL.cs 里面的sql一般用const 或static定义string类型即可。
收获园豆：5
0
据说是DAL~
0
一般来说，肯定是DAL，如果BLL碰了SQL，可以说分层的意义就被打破了
你可以把DAL再分出来一层，一层可能死更加基础的CRUD方法，另外一个作为Facade进行包装，可能会组合一些复杂的存储过程或者SQL语句，像你说的重复发明轮子的情况，应该是你的方法不够抽象，需要重构
收获园豆：20
是否可以举例说明。这样更具说服力和感染性。也通俗易懂。
0
DAL
0
主要的是DAL，其实三层现在都没有一个明确的定义，理论上不能放到BLL，实际上BLL是经常放一些select
0
dal层写的不够灵活，完善；建议用orm。
收获园豆：5
那要如何灵活发？兄台请举例说明。太抽象了，我也不好理解。
0
为什么SQL是数据访问，而不是业务逻辑
