1,265
社区成员
发帖
与我相关
我的任务
分享关于业务逻辑与数据库分离的问题。
在面向对象的设计时，不可避免的要涉及到对象的持久化问题。由于目前关系型数据库的流行及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 " 不是更好么？
大家对这个问题怎么看？
...全文
请发表友善的回复…
发表回复
wxt 2005-03-25
- 打赏
- 举报
对于搂主这个问题,我觉得关键还是楼主没有领会proxy模式的真义,楼主说"orderproxy从ORDER表中取出ORDER对象，然后从ITEM表中取出该订单的所有订单项并加到ORDER对象中。然后调用ORDER对象的TOTAL方法。"
但为什么一定要用这种方式使用proxy呢?对于这类问题,完全可以把后面带sum()的SQL语句封装到一个特定类中,然后proxy发现total的是这类特定问题时,就不按默认的逻辑执行,而是直接调用特定类的方法,然后把SQL语句执行的结果给Total方法就可以了.因为对客户而言,它要的是total的结果,而不关心total的数据是怎么来的.代码写出来大概就是这个样子
Select Case 请求的Total操作
Case 一般操作
使用标准逻辑
Case 订单统计
使用特定逻辑
End Select
但为什么一定要用这种方式使用proxy呢?对于这类问题,完全可以把后面带sum()的SQL语句封装到一个特定类中,然后proxy发现total的是这类特定问题时,就不按默认的逻辑执行,而是直接调用特定类的方法,然后把SQL语句执行的结果给Total方法就可以了.因为对客户而言,它要的是total的结果,而不关心total的数据是怎么来的.代码写出来大概就是这个样子
Select Case 请求的Total操作
Case 一般操作
使用标准逻辑
Case 订单统计
使用特定逻辑
End Select
wxt 2005-03-25
- 打赏
- 举报
对于搂主这个问题,我觉得关键还是楼主没有领会proxy模式的真义,楼主说"orderproxy从ORDER表中取出ORDER对象，然后从ITEM表中取出该订单的所有订单项并加到ORDER对象中。然后调用ORDER对象的TOTAL方法。"
但为什么一定要用这种方式使用proxy呢?对于这类问题,完全可以把后面带sum()的SQL语句封装到一个特定类中,然后proxy发现total的是这类特定问题时,就不按默认的逻辑执行,而是直接调用特定类的方法,然后把SQL语句执行的结果给Total方法就可以了.因为对客户而言,它要的是total的结果,而不关心total的数据是怎么来的.
但为什么一定要用这种方式使用proxy呢?对于这类问题,完全可以把后面带sum()的SQL语句封装到一个特定类中,然后proxy发现total的是这类特定问题时,就不按默认的逻辑执行,而是直接调用特定类的方法,然后把SQL语句执行的结果给Total方法就可以了.因为对客户而言,它要的是total的结果,而不关心total的数据是怎么来的.
hmyujian 2005-03-02
- 打赏
- 举报
mark!!!!
zengjd 2004-11-18
- 打赏
- 举报
转贴:来自Delphibbs.com
就我们现在的项目，说一下我们的分层思想。有兴趣的可以讨论。。
主要的分层思想还是：MVC
分为：BLL、BAL、UI
实现方式：
1.Bll层
Bll主要的放和数据库进行交互的类，主要包括类分为SQLHelper、DataManager
SQLHelpher的主要功能和微软写的那个基本类似
DataManager主要包括的功能：
(1)主要的完成动态的构造SQL语句[增、删、改]通过一个XML的配置文件实现[这个文件是通过写了一个通用的方法，提取数据库中的数据结构。自动生成的]，结构完全和数据库表结构相同，可以指定是否为自增字段或主键字段
(2)动态的把传递过来的DataRow拆分成相应的增、删、改对应的参数数组
2.UI层主要就是把数据打包成DataSet
首先把UI中处理的数据都放到一个DataSet包中（里面包括若干个table）。之后把这个DataSet包作为一个参数，传递到BAL中进行处理。
3.BAL层
BAL主要的是解析UI层传递过来的DataSet，之后把每个DataSet分DataRow进行处理，调用DataManager中的方法，构造SQL语句和相应的构造参数数组。之后调用SQLHelpher中的ExecuteNoQuery方法完成数据的增、删、改操作。
体会：
优点：可以动态的构造SQL语句，动态的解析DataRow构造成参数数组。之后进行数据的处理，方法是通用的。不用每个都拼SQL语句。
BAL层的类可以实现复用[因为都是通过一个通用的方法解析DataSet]，即使数据结构变了，该曾也不用做任何的修改。
就我们现在的项目，说一下我们的分层思想。有兴趣的可以讨论。。
主要的分层思想还是：MVC
分为：BLL、BAL、UI
实现方式：
1.Bll层
Bll主要的放和数据库进行交互的类，主要包括类分为SQLHelper、DataManager
SQLHelpher的主要功能和微软写的那个基本类似
DataManager主要包括的功能：
(1)主要的完成动态的构造SQL语句[增、删、改]通过一个XML的配置文件实现[这个文件是通过写了一个通用的方法，提取数据库中的数据结构。自动生成的]，结构完全和数据库表结构相同，可以指定是否为自增字段或主键字段
(2)动态的把传递过来的DataRow拆分成相应的增、删、改对应的参数数组
2.UI层主要就是把数据打包成DataSet
首先把UI中处理的数据都放到一个DataSet包中（里面包括若干个table）。之后把这个DataSet包作为一个参数，传递到BAL中进行处理。
3.BAL层
BAL主要的是解析UI层传递过来的DataSet，之后把每个DataSet分DataRow进行处理，调用DataManager中的方法，构造SQL语句和相应的构造参数数组。之后调用SQLHelpher中的ExecuteNoQuery方法完成数据的增、删、改操作。
体会：
优点：可以动态的构造SQL语句，动态的解析DataRow构造成参数数组。之后进行数据的处理，方法是通用的。不用每个都拼SQL语句。
BAL层的类可以实现复用[因为都是通过一个通用的方法解析DataSet]，即使数据结构变了，该曾也不用做任何的修改。
amanda2lxn 2004-11-10
- 打赏
- 举报
In my opinion:
In j2ee blueprint, the function of database is only store related data; we put the business in application server.
but why we use "proxy”, for example, imaging, if you develop a huge application with a lot of data stored in different database, must of time , you need application server to set up the balance. So the functional area of data store, data operate, data access are separate in order to get the best performance.
In j2ee blueprint, the function of database is only store related data; we put the business in application server.
but why we use "proxy”, for example, imaging, if you develop a huge application with a lot of data stored in different database, must of time , you need application server to set up the balance. So the functional area of data store, data operate, data access are separate in order to get the best performance.
zhang_yzy 2004-11-06
- 打赏
- 举报
我看过一本《VB开发规范》（名称记不清了），上面有一部分是关于程序分层的，我觉得很有趣，你可以去找找看看
zhang_yzy 2004-11-06
- 打赏
- 举报
学习
我认为：数据分离的优点是显而易见的，
但是有人说会导致层次不清，我觉得那不应该说成是有数据分离来负责，那只能说是那种方法还有问题，需要进行改进
我认为：数据分离的优点是显而易见的，
但是有人说会导致层次不清，我觉得那不应该说成是有数据分离来负责，那只能说是那种方法还有问题，需要进行改进
billy_zh 2004-10-31
- 打赏
- 举报
学习!
既然使用OO，那么O/R Mapping是很重要的，
介绍大家看一下NHibernate(.net), Hibernate(java),
它同样可以使用sql中的函数（当然包括统计函数），但它是面向对象的哦~
我的小站http://www.narchitecture.net/有一些关于nh的文章.
既然使用OO，那么O/R Mapping是很重要的，
介绍大家看一下NHibernate(.net), Hibernate(java),
它同样可以使用sql中的函数（当然包括统计函数），但它是面向对象的哦~
我的小站http://www.narchitecture.net/有一些关于nh的文章.
Mybeautiful 2004-10-30
- 打赏
- 举报
这个例子是取自《敏捷软件开发》一书的，正好在看此书，有个问题不太明白想请教楼主及各位高手们：类orderimp在其中究竟起到什么作用呢？我感觉直接应用orderproxy就可以了。
------------------------
从楼上得到的信息,似乎可以总结如下:
Order, 提供接口
orderimp,实现算法(数据结构)
OrderProxy,真正与数据库打交道.
具体如何组合,怎样协调工作,待研究....
------------------------
从楼上得到的信息,似乎可以总结如下:
Order, 提供接口
orderimp,实现算法(数据结构)
OrderProxy,真正与数据库打交道.
具体如何组合,怎样协调工作,待研究....
simonzone 2004-10-29
- 打赏
- 举报
等
-勇敢的心- 2004-10-04
- 打赏
- 举报
up
kissheart 2004-10-03
- 打赏
- 举报
这个论题很好啊，我最近的项目中用到了gotdotnet中的data access application block,利用抽象工厂模式实现了根据数据提供程序使用不同数据源。可以使用相同的Provider调用不同的数据源。不必为了不同数据源而重写Provider。
下载地址：http://www.gotdotnet.com/workspaces/releases/viewuploads.aspx?id=c20d12b0-af52-402b-9b7c-aaeb21d1f431
下载地址：http://www.gotdotnet.com/workspaces/releases/viewuploads.aspx?id=c20d12b0-af52-402b-9b7c-aaeb21d1f431
qiao_feng2002 2004-09-27
- 打赏
- 举报
肯定有你的说的方法以外的方法，而且没有你说的代理法的缺陷。可惜我不知道。
等于没说，是吗？
等于没说，是吗？
mahaixing 2004-09-27
- 打赏
- 举报
简单最好，设计模式是为了解决相对应的问题。
我觉得不应为了套用设计模式而使得代码变得复杂难懂。
如果应用程序仅仅是操作数据库，那么把sql直接写到数据库里面也不见得是坏事。
当业务逻辑复杂的时候那么在使用设计模式将数据操做与业务逻辑分开。
我觉得不应为了套用设计模式而使得代码变得复杂难懂。
如果应用程序仅仅是操作数据库，那么把sql直接写到数据库里面也不见得是坏事。
当业务逻辑复杂的时候那么在使用设计模式将数据操做与业务逻辑分开。
uuxiaoli 2004-09-25
- 打赏
- 举报
学习
goldocean 2004-09-23
- 打赏
- 举报
up
maksim_wei 2004-09-14
- 打赏
- 举报
学习
Mybeautiful 2004-09-09
- 打赏
- 举报
此贴可以再up....
princeahan2003 2004-09-09
- 打赏
- 举报
我提倡直接用SQL,搂主的方法实现起来麻烦，而且最主要的是不灵活，复杂查询不行。
效率也的确是个问题。
SQL还可以用properties文件管理。
至于什么今后的扩展，我做了6年了，扩什么展，很少有项目是要做什么扩展的，都是直接上2期，
我们的做法一般都是DAO方式，或者直接有一个db构件，用来执行sql的，sql通过properties文件统一管理
效率也的确是个问题。
SQL还可以用properties文件管理。
至于什么今后的扩展，我做了6年了，扩什么展，很少有项目是要做什么扩展的，都是直接上2期，
我们的做法一般都是DAO方式，或者直接有一个db构件，用来执行sql的，sql通过properties文件统一管理
zengjd 2004-09-09
- 打赏
- 举报
>>princeahan2003(princeahan)
能不能把你的经验具体谈一下，这么多兄弟都在迷茫中呢！指点一下吧！谢谢！
能不能把你的经验具体谈一下，这么多兄弟都在迷茫中呢！指点一下吧！谢谢！
加载更多回复（73）
