讨论一下数据访问层用什么方式来写好
最近在做一个的个大型的OA系统 最近在讨论数据层上发生了分歧
同事一队要求数据访问层使用存储过程的方式 然后 业务逻辑层写成调用存储过程的方式
另一队要求数据访问层使用通用存储过程的方式，然后业务逻辑层调用数据访问层（SQL语句写到这一层），，

请问对这个两个需求有什么看法？哪个更好一些？优点各是什么

------解决方案--------------------
存储过程一般会将业务层与数据层结合了.

依据项目而定,依据你们团队的结构而定.
------解决方案--------------------
全部业务写在数据库中.这是最好的方式.不过要求DBA有很高的能力.
国内一般没有企业这样搞.
------解决方案--------------------
大型的还是用“同事一队要求数据访问层使用存储过程的方式 然后 业务逻辑层写成调用存储过程的方式”这种方式好
------解决方案--------------------
好像你说的都差不多吧。
要求数据访问层使用存储过程的方式
要求数据访问层使用通用存储过程的方式

－－－－－－－－－－－－
不都是存储过程。然后你业务那层都是调用这个层来对数据调用？
------解决方案--------------------
什么是通用存储过程的方式？
------解决方案--------------------
个人倾向于后者。可以把一部分工作交给SP来做，但一般情况下的业务逻辑我觉得还是放到代码中比较好。
如果你的OA系统不是极大规模的话，以现在的服务器的性能，这点损失比起所得，我觉得真是方便多了。
------解决方案--------------------
这两个方案要结合起来用吧，其实楼主的问题无非是问“用存储过程好”还是“用SQL语句好”
------解决方案--------------------
写个SQLHelper就可以了
------解决方案--------------------
需要看你们是做项目还是做产品。

如果是做产品，那么可能要支持多种服务器。存储过程的方式，这个时候可能会有些问题，
因为存储过程在每种数据库实现的方式不同。

如果是做项目，也要看部署方式和参与人员的水平和强项。
如果是部署程序不方便，而且参与项目人员的sql功底非常强悍，那么，可以用存储过程的方式去做。

但是存储过程有些东西写起来，有些人喜欢一个业务逻辑写一个存储过程，
导致很多类似的存储过程代码重复。
而且存储过程较难测试，比如重构的时候。

这个算是存储过程的缺点吧。

如果逻辑写成代码，而且分层严谨，面向抽象的话，整个代码之后功能修改，重构，测试，都会比较方便。
比较麻烦的是如果有逻辑更改的话，部署起来比较麻烦。

总之，要用什么方式去做，需要看实际情况和参与人员来定
------解决方案--------------------
PetShop3.0这种方式，我觉得比较好。
------解决方案--------------------
本人喜欢直接写语句，慢了一点，但是开发时的效率高得多
------解决方案--------------------
业务逻辑不同，对数据的操控能力要求也不同，对数据操作比较频繁的建议多应用存储过程和视图的功能。如果对数据掌控之外还要增加状态监视、通知等数据以外的后处理，则应该偏重于业务逻辑层和数据访问层的分离。
------解决方案--------------------
我喜欢用TableAdapter
------解决方案--------------------
如果沒什么必要不用分很多成，邏輯層調用存儲過程就好了！
------解决方案--------------------
从性能上讲，没什么差别
不过存储过程依赖比较强，一般大型项目都直接写sql