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