一
一
Unregistered / Unconfirmed
GUEST, unregistred user!
在面向对象的设计时，不可避免的要涉及到对象的持久化问题。由于目前关系型数据库的流行及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 " 不是更好么？
大家对这个问题怎么看？
但一般认为数据库是实现细节，应该和业务逻辑对象分离，以保持业务对象的可复用性及可扩展性。为了业务逻辑与数据库分离，比较常见的推荐的做法是使用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 " 不是更好么？
大家对这个问题怎么看？