封装业务逻辑是用业务逻辑层还是存储过程!?

 今天，和一个朋友聊天，他是做.NET开发的（PS:鄙人是Java的虔诚信徒），朋友说他们最近在做的一个项目，使用了400个左右的存储过程代码封装 了整个逻辑!光是存储过程代码在50000行左右!由此引发了我对软件开发的一些思考，我在此只是抛砖引玉，欢迎大家参与讨论！

    现代软件开发为什么要分三层甚至n层，无非是为了实现“强内聚、松耦合”的目标，将软件“分而治之”，把问题划分开来各个解决，易于控制，易于实现组件重用，易于扩展和维护，易于分配资源。大大降低了开发和维护的成本，其优势不言而寓。

    以下是鄙人的一些愚见，有不对的地方望指正！

    1. 对于小项目，业务放存储过程里编程最简单，详细写好注释，避免数据从数据库到程序的来回传递，这也是存储过程的优点。
    2. 但是对于中大型项目，访问量很大，若将业务逻辑大量封装于存储过程中会导致数据库压力太大，中间层压力太小，资源闲置。这时就应该把业务放到中间层，中间层压力大的时候容易做服务器Cluster，做负载平衡。
    3. 做产品的时候，考虑到产品的移植性和安全性，应该尽量避免存储过程。
    4. 多人开发的时候，存储过程不是很方便做版本控制和管理。
    5. 关于Debug，调试不是很方便。
    6. 如果sp中有一大堆if, case, 然后每个begin  end之间有一大段处理, 甚至if case 还不断嵌套, 我认为这是在滥用sp, 这个应该是程序去完成的；   
      如果程序中从数据库中不断的拉数据和缓存数据,   结果就是为了几个表关联出点什么东西,   我认为是在滥用程序,   这个应该是sp去完成的

    7.存储过程的执行效率确实比较高，一些O/R mapping 框架如Hibernate则有性能瓶颈问题，用得不好会导致性能的下降，个人认为用ibatis 再在适当的时候结合使用存储过程，这样既可以兼顾OO的设计，又可以兼顾性能问题。