关于业务逻辑与数据库分离的问题。

Question

在面向对象的设计时，不可避免的要涉及到对象的持久化问题。由于目前关系型数据库的流行及SQL语言的强大功能，一般都以关系型数据库存储要持久化的对象。但一般认为数据库是实现细节，应该和业务逻辑对象分离，以保持业务对象的可复用性及可扩展性。为了业务逻辑与数据库分离，比较常见的推荐的做法是使用Proxy模式。举个例子如下：有一个订单类Order,它包含一些订单项Item。象这样的对象的持久化问题大家都非常熟悉了。就是有个ORDER的表来存储ORDER对象，这个表有个ORDERID关键字用来唯一标识每个Order对象。还有一个表ITEM用来存储订单项，每个ITEM通过ORDERID同ORDER表关联。假设使用PROXY模式分离Order的业务逻辑与数据库的做法是：Order分成3部分。第一部分是一个接口order，其中包括客户要调用的所有方法。第二部分是一个类orderimp，它从接口继承，它在不涉及数据库的情况下实现接口中的所有方法，第三部分是一个知晓数据库的代理类orderproxy。它也从接口继承.比如现在我要计算某订单的总金额。ORDER接口有个TOTAL方法来实现这个业务问题。PROXY的工作原理是，客户使用调用ORDER接口的TOTAL方法。orderproxy从ORDER表中取出ORDER对象，然后从ITEM表中取出该订单的所有订单项并加到ORDER对象中。然后调用ORDER对象的TOTAL方法。这样做的好处是。数据库完全不参与业务逻辑，实现了业务逻辑与数据库分离。但我认为这样做的代价是比较大的，特别是订单项比较多并且业务逻辑非常复杂的情况下。从数据库中取出数据组合成对象，然后通过对象完成功能不但增加了实现的复杂性并且效率也是个问题。如果直接用SQL语句完成，虽然偶合了业务逻辑，但简单直接，而且效率比较高，　其实上边的问题直接用SQL语句“select sum(item.price*item.quantity) from item where orderid= n "　不是更好么？大家对这个问题怎么看？
  

Answer 1

分离的最大作用是提高维护性能，但是我觉得很多数据库本身在它们设计之初就与业务有很多撤不清的关系，要做到业务与数据库完全分离感觉很难。
至于效率问题，我想这和规模有很大关系，如果一个软件的规模小，用这种分离的效率就相对于大规模的系统低很多，而且也没有必要。
这是个人意见，经验不多，请各位大侠多多指教。

Answer 2

我觉得，软件的规模的大小对于分离所带来的效率的影响好像关系不大。如果分离会带来效率的影响，那么恰恰大规模的软件不因该分离，因为大规模的软件操作大量数据的可能性更大一些，所以更需要高效率！但是大规模的软件得维护工作更大，却需要分离，这就到了两难的境地！或者有更好的分离办法？或者真正项目根本不需要分离？

Answer 3

〉〉很多数据库本身在它们设计之初就与业务有很多撤不清的关系这种撤不清一般会体现在哪里？可不可以继续指教？

Answer 4

我指的效率是开发效率，执行效率可以通过其他的方式解决(比如设计好的算法).
至于这种撤不清的关系问题,我想在现实世界中一个对象的特征和他所处的环境有很大的关系，环境决定影响了他的特征,同样的业务逻辑好比现实世界世界的环境,数据库就好比对象的特征.
不知道我有没有表达清楚，我也没有做过这方面的工作，这只是我主关的想法，因为在自然界中任何一个生物不能脱离环境而存在

Answer 5

分离对于执行效率的影响是无论设计如何好的算法都有的，因为他要先实例化对象，在执行业务逻辑！特别是数据量大的时候，对与执行效率的影响是非常大的，况且对于象本问题这样的，有什么更好的方法能提高执行效率么？对于你说的“对象的特征和他所处的环境”我不大明白！
希望大家更深入的讨论这个问题！

Answer 6

要分离，就要牺牲数据感知控件带来的方便性。
这一直是痛苦的根源。
我在写程序的时候，很多原来的思路到了这里只好放弃。