因为在分析设计阶段就引入了数据库概念，所以导致最后编程结果混合在一起。
重构的最好办法就是从源头开始，重新使用新的方式DDD等OO建模来进行需求分析设计，画出领域模型图，使用Hibernate这些O/R Mapping框架，从分析设计编程三个阶段断绝数据库情结，彻底割去数据库癖好，这样方能真正将业务逻辑从数据库恶梦手中夺取出来。
希望越来越多意识到：不要让自己的业务逻辑被数据库恶梦劫持。
相关话题:
http://www.jdon.com/jivejdon/thread/32685.html
[该贴被banq于2007年09月19日 10:28修改过]
如果说重新构架整个系统，现在对我们来说是不现实的。可否先从系统中的一个模块开始，按照DDD的方式重新建模，重新实现，逐步完成整个系统的重构？
可以，重构从模块开始，首先把这条路走通，因为自己的OO建模能力也是逐步提高的。
偶觉得完全和数据库分开是做不到的，毕竟不同的数据库很多地方的特性不一样，甚至很大的差异。
用hibernate中间件调优是个问题，关键是有可能和你理解真实的逻迹执行有差异。
呵呵
多谢发言，个人认为这是完全错误的看法，现在好的OO三层就做到分开了，大量实例在那里，为什么要分开呢？很简单，不能和具体数据库技术耦合，这样妨碍软件的拓展性。
不将数据库这个恶魔压在持久层这样雷峰塔下，你的软件永远别谈扩展性和灵活性。如果这点不同意，就无法沟通，就是两个世界的人了。
我来说一下，这种系统，想重做是不现实，重构，楼主我不是打击你，也基本上没戏，除非你们项目组都开始OO，并且有领导支持。为啥这么说呢？
1.当逻辑在表里，就相当于死在表里了
2.重构与重做，部分重做的差别还是很大的
3.当你的系统中有一部分通过”重构“达到OO而其他东西还死在数据库中的时候，你的系统也就快死了。
4.你的系统即使OO也无法把逻辑与数据库分开，除非你改数据表，或者通过视图，但数据迁移之类的工作肯定不会小。
反正，我是吃过这么一次亏了，一个中型系统就是死在数据库中，最后全重做的。
我来说一下，这种系统，想重做是不现实，重构，楼主我不是打击你，也基本上没戏，除非你们项目组都开始OO，并且有领导支持。为啥这么说呢？
1.当逻辑在表里，就相当于死在表里了
2.重构与重做，部分重做的差别还是很大的
3.当你的系统中有一部分通过”重构“达到OO而其他东西还死在数据库中的时候，你的系统也就快死了。
4.你的系统即使OO也无法把逻辑与数据库分开，除非你改数据表，或者通过视图，但数据迁移之类的工作肯定不会小。
反正，我是吃过这么一次亏了，一个中型系统就是死在数据库中，最后全重做的。
2）也没必要非得把所有的业务逻辑全搬出来。某些事还是在数据库里做有好处。OO是好东西，可DB也不是洪水猛兽。
http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=36063&message=23122681#23122681
[该贴被banq于2009-05-30 17:13修改过]
人家干完了家务，缓存跑来抢功劳？
如果这些业务逻辑和判断所需的数据量很大，而逻辑和判断结果需要返回的数据量很小。我认为存储过程也许是个好的方案。
试想你需要统计一亿条数据，计算总数，平均数等等。是在数据库里完成快，还是把数据都读到应用服务器，缓存后，再计算快呢？
不要把数据库一棍子打死，采用什么做法要看具体问题。
数据录入部分用应该是用存储过程吧。
这样就能保证数据库的逻辑和应用的逻辑分开了。
换什么数据库都应该没关系了。
我们部门不处理数据录入部分。在检索部分我们部门就是用视图做的隔离，效果很不错。
“必须认识到：业务逻辑和数据库混合在一起是来源于软件的源头：分析设计阶段。
因为在分析设计阶段就引入了数据库概念，所以导致最后编程结果混合在一起。”
我认为不是这样的，在需求分析阶段专门有一部分叫相邻系统。
我觉得需求分析阶段时要确定数据库的。书上说需求阶段要确定和你系统通讯的系统是什么，我理解为包括数据库。