数据库访问层架构的问题
之前数据库访问层的SQL放在C#中，针对每个表都有Select,Update,Insert,Delete操作，然后再在上层组合需要的逻辑结构。
现在老板让用存储过程来实现，告诉我们这样做一大堆好处之类的，让我们实现。我的疑惑是方案选择
1：用存储过程来实现每张表的Select,Update,Insert,Delete操作，然后在用代码组合业务逻辑
2：直接根据业务逻辑来写存储过程

这两种应该用哪一种呢？老板说用第二种，但是我觉得应该用第一种。
------解决方案--------------------

引用:

之前数据库访问层的SQL放在C#中，针对每个表都有Select,Update,Insert,Delete操作，然后再在上层组合需要的逻辑结构。

那种“为了三层而三层”DAL代码没有什么意义。既然只是针对表进行增删改查，直接使用sql语句就行了。重启量，你们可以针对不同的关系数据库使用不同的资源文件而切换不同的sql语句字符串集合（何况通常并不需要考虑切换数据库的问题）。

把DAL当作这种东西，没事的时候会找事出来、搞各种奇怪的东西，根源都是一样的。

你们在BLL中直接访问数据库，例如使用ADO.NET或者EF之类的就行了，或者说只要有SQLHelper之类的就行了，不要去搞肤浅的DAL。

至于说使用不使用存储过程，我不作评论。这是可以选择的！

但是无论如何也不至于把“增删改查”这种最浅、最原始的sql语句再一次封装成存储过程。
------解决方案--------------------
用存储过程来实现每张表的Select,Update,Insert,Delete操作，然后在用代码组合业务逻辑

和直接通过sql查询表和视图有什么区别？起码你得有个理由先。