存储过程和分层的讨论。。存储过程与分层难道真的是对立的吗？欢迎大家来各抒已见。

只谈一点自己做项目时的经验，
存储过程一般都是用来做基础数据准备，如数据导入导出什么的，里面不会有很复杂的逻辑判断之类的。
具体的业务逻辑还是写在service层的好，可以充分利用应用服务器的优点，主要还是易于维护

解决方案 »

  1.   

    看来大家都还是比较推荐尽量少用存储过程。
    我的想法跟楼上的差不多。。我发现如果把过多的数据操作放在存储过程中，对系统以后的维护和扩展是个大问题。而且我发现编写存储过程与用JAVA来控制逻辑很麻烦，特别是调试和测试时候。可能这也只是个人感觉而已。
      

  2.   

    维护不只是修改bug，还包括可能的需求变更和功能的扩展，分应用层和数据层很大部分就是为了应对这种情况的出现，好的系统应该是符合开闭原则：对扩展开放，对修改关闭。说的好像有点多呵呵，存储过程在这种情况下就是不停的改了
    所以对于比较固定的业务处于性能的考虑当然可以写存储过程，但是面对客户脑子里风云变换的古怪想法，还是分层的好
      

  3.   

    存储过程做成接受参数, 原封不动的去更新DB. 所有数据处理都由业务逻辑层去做. 业务逻辑层用来处理 视图bean 传来的数据,进行验证,计算或一些处理, 然后组成参数传给存储过程.   一个业务逻辑层可能有好几个子逻辑, 那么就可以表现为调用了多个存储过程.  所以存储过程在业务逻辑这边是可以重用的.(个人意见~ 这样看, DAO是没啥意义~ 啥事也不干,纯粹把数据从一个存储方式转到对象存储方式, 还是免了吧~ )