业务逻辑的定位: 向java走，还是向数据库走?

怎麽設計是看情況而定的，沒有什麽樣的design是最好的，適用就ok

非也～
如果你的应用足够大，那么存储过程就是要把你们繁杂的业务逻辑扎进数据库中去。而业务多半是经常有变化的，小修小补更是家常便饭，特别是做电子商务这块儿。是不是每次业务变动都必须要改复杂的存储过程然后再在数据库中重新编译呢？

所以，我个人还是支持将业务的代码放到java应用程序中去。但我们大家都明白业务的描述代码是整个应用中最丑陋的一部分，并且这个部分所占的总比例还很大，它们看上去就像“脚本”，或许还充满if...else，非常丑陋；而且，据我所知，不管工程思想多么进步，新型框架多么先进，多么地吹嘘能够“简化开发”或“快速开发”，这些脚本式的业务逻辑描述代码的丑陋面貌都没有得到多大改善，它们的数量也没有明显减少过——这个很好理解：你的业务如果本身就很复杂，你还能指望用更少的代码去描述它们吗？那些新型框架所“简化”或“消灭”的东西都是一些“本来就可有可无”的东西，像什么vo啊，DO啊，什么什么O之类的；而真正描述业务的东西——该出现的它还是照样会出现的——以同样丑陋的面貌——一点也没变过。
我刚才好像说到了“脚本”，是的，这些业务代码其实就是脚本，而且我们用java来写这些“脚本”更是加大了我们的痛苦，所以，我认为业务逻辑将继续留在应用程序中，但应该由一种更适合编写“脚本”的东西来描述它，而不是java。
我们可以继续用java定义一系列的service，一系列的domain model，这些东西就像是等待演出的演员。而业务逻辑代码就是这些演员的剧本，它以剧本（或者说脚本）的形式描述了这些演员是怎么互相交流的，进而完成了什么样的业务。好了，DSL的概念在这里应该已经出来了，是的，我就是说这个。对于某种特定的行业（首先把范围缩小），应该可以定义某种尽量接近自然语言的形式语言，来写这些“剧本”，到那时候，这些丑陋的代码将大大瘦身，并且可能出现“代码即业务文档”的情况。这应该算是一个远期目标，不过我觉得jbpm之上的jpdl已经有点这种业务脚本的倾向了，只不过它是xml的形式的（其实它那种xml就可以叫做一种脚本语言）。不过jpdl还太“普遍性”，也就是不够“专”，没有针对某个特定行业的业务；但不久以后应该能出现为某个行业定制的jpdl，我觉得这是肯定的。
另外，刚才没说到数据库访问的问题，我觉得读取数据量多少一般不是什么问题，因为一个业务，不管你是存储过程来做还是程序来做，只要涉及查询的，都会有一些数据读入和输出，“量”上看不出什么太大差别。差别在执行效率上，你不能然压在数据库上的压力过大，所以cache是用来减少数据库压力的。

只能说各自有自己的应用环境了，我曾经给NOKIA做的一个项目里就是用存储过程，效率比用service提高了将近10倍

看你做什么了。
如果做电子商务业务，业务逻辑比较复杂，外部业务关联性特别多。用个什么J2EE框架，高个什么3层结构，多少有点儿用处的。至少“框架框架”，就是来“框”住程序员的，让他别天马行空的扒拉代码。
如果是一些特定的应用系统，比如电信计费系统，最好让经验丰富的老程序员全部写成存储过程。第一：速度快，稳定。第二：计费策略不是每天都变，就算1个月变一次，也赶得及。第三：这种系统的维护预算都比较高，完全能支撑一队常年的存储过程老手们的成本。如果把这中业务放在Java应用层实现，九成达不到性能、稳定性要求。

具体情况具体对待，变更风险小成本低稳定性高的最好．使用存储过程最好有个很完善的文档记录，要不然可能很快就混乱起来了．

跟你有相同的感受，我也很讨厌将业务逻辑放在存储过程中。
对于存储过程，如果为了实现一些逻辑有可能要写上百甚至上千行，过段时间，你回头FIX BUG的时候，
有可能你自己都没有什么印象，更别说遗留给其他人了。
还有就是如果你做数据库移植的话，估计也要死人。

还是看具体情况了。一般放在Java中好维护一些，少部分对性能敏感的代码，特别是需要循环处理的，可以放存储过程中。

具体情况具体分析，个人觉得有几点可以考虑一下：
1，你的系统要不要支持多种数据库（如果是产品的话，这个会要求得比较高一点）
2，你对性能要求是怎么样的（这只是个假想，并不一定存储过程就会比Java代码性能高，要考虑到你们的db server和app server的情况）
3，你们的人力资源怎么样（如果其它条件无所谓的话，那么选择你们绝大部分人熟悉的技术吧）
4，。。。。。。

补充一点，就是在我们设计时，要想好到底是用db function还是用Java，最好不要出现相同的业务背景，有些地方用Java有些地方却用db function的情况

我个认为是没有绝对的，几年工作下来，发现在初始化和报表的地方用的储存过程多一点，其实用在这里的好出就是根据你数据库的自身的规则进行性能的提升是很明显的。用Java并不会见得一定比它快吧。
当然也要看你的系统是不是要支持多数据库咯，如果要的话，那可能用储存过程会有点麻烦。我不同意储存过程难维护的观点。

还有就是你用JAVA来实现的话，如果有问题。你要修改在发布到正式机器，你想想会有什么后果？如果是储存过程就不会了。