我们在开发系统时,一般VO（或者是PO）对应的是数据库中的表中的记录，view object是提供给客户端显示用的对象，在业务逻辑部分是BO。在很多情况下，我们把VO或者是PO作为了BO，但是在复杂的业务环境中，这种方式的脆弱性就体现出来了，如果我的业务对象比较复杂（具体来说，比如包含了多个表，多个视图中的数据），就没办法将VO、PO作为BO用了。这时候我们需要专门做一层业务层，通过拼装软干个PO、vo来构造我们需要的BO，以及按一定的业务逻辑处理这些BO，并生成相应的view object提供给客户端。我的疑问是：
1、这方面有没有成熟的架构或者案例？
2、关于BO的构成：
2.1、BO中是否应该既包含业务对象的属性又应该包含业务方法？
2.2、或者是BO只包含业务对象的属性，对BO的所有操作都由业务逻辑对象处理？
2.3、或者BO中包含业务对象的属性以及Retrieve，Update，Create，Delete等操作，而业务逻辑由专门的业务逻辑对象处理？
 Re: 关于BO的问题  发表时间: Jul 17, 2005 7:55 AM   回复 
 
发表人: banq    发表文章: 5226 / 来　　自: 上海 / 注册时间: 2002-08 
你的疑问正好和这篇文章讨论的一致：

BO中是否应该既包含业务对象的属性又应该包含业务方法？
在Ruby on Rails/Naked Objects精神指引下的域驱动开发框架

>1、这方面有没有成熟的架构或者案例？
你这是SOA架构，是业务层加Domain，现在大量的J2EE都是这种架构

》2、关于BO的构成：
》2.1、BO中是否应该既包含业务对象的属性又应该包含业务方法？
现在SOA架构是不包括业务方法，被称为贫血模型;Naked Object是两者都包括，但这是一个研究方向。
>2.2、或者是BO只包含业务对象的属性，对BO的所有操作都由业务逻辑对象处理？
是的
>2.3、或者BO中包含业务对象的属性以及Retrieve，Update，Create，Delete等操作，而业务逻辑由专门的业务逻辑对象处理？
一般BO只包括属性，CRUD也属于业务操作了，我认为属性和业务方法分离属于桥模式，分离是为了更灵活的组装，SOA也不违反OO，不过因为OO的"教皇"Martin fowler一句来自感觉的话：感觉不美，贫血模型；我相信不出，在一个分布环境中和一个互联共享环境中，如果把BO拿出来共享，而不是Service，会产生什么样后果。也许“教皇”不是凡人，比你我看得很远，可惜我是倡导“上帝死了”的人。

 
 

 Re: 关于BO的问题  发表时间: Jul 18, 2005 12:46 PM   回复 
 
发表人: redlly    发表文章: 42 / 注册时间: 2003-07 
SOA好象是基于服务的架构,能说说和这个具体有什么关系吗?
 
 

 Re: 关于BO的问题  发表时间: Jul 23, 2005 11:01 AM   回复 
 
发表人: flyinair2000    发表文章: 10 / 注册时间: 2004-08 
Martin fowler一句来自感觉的话：感觉不美，贫血模型
－－－－－－－－－－－－－－－
这根本不是感觉的话，这样的模型又回到了procedural programming的老路上了。
procedural progrmming 告诉我们“世界就是世界，你就是你”。
oo说“世界就是你，你就是世界”。
现在多了一个SOA这个BUZZWORD，说的却还是“世界就是世界，你就是你”。除了在哲学理论上我可以看出它的“螺旋式上升”的进步以外，其他看不出有什么意义。（以上的“世界”和“你”　差可比拟为“method"和“property")

另外，什么是soa? 谁也搞不清楚。（看最近TSS.NET上的一篇，MS　（PDC?) 2005 大会上谁都讲SOA,谁都说不清。但是已经有architect宣称SOA是类似于oo　的paradigm shift了，搞笑不搞笑？）
近来如果可以算作paradigm的话，个人认为恐怕要数AOP为代表的方面编程了。
 
 

 Re: 关于BO的问题  发表时间: Sep 9, 2005 8:30 AM   回复 
 
发表人: Kyle_Yin    发表文章: 26 / 注册时间: 2005-09 
"这根本不是感觉的话，这样的模型又回到了procedural programming的老路上了。"

除了OOP还是PROCEDURAL的编程风格之外, 其实这里有令一个重要因素大家没有提及: 性能.

很多大系统, 至少我听说过(看过DIAGRAM)的和亲眼见过(CODE)的系统(呵呵, 其实也没几个), 大多是尽可能采用无状态设计. 无状态的组件界面看上去当然象PROCEDURAL函数. 这样做的原因, 主要是为了性能. 在分布计算环境里, "状态"往往意味着"地点亲合", "地点亲合"往往意味着"性能瓶颈".

我发现直白英文翻译成中文马上就发酸了.

 
 

 Re: 关于BO的问题  发表时间: Jul 23, 2005 11:07 AM   回复 
 
发表人: flyinair2000    发表文章: 10 / 注册时间: 2004-08 
或者是BO只包含业务对象的属性，对BO的所有操作都由业务逻辑对象处理？
------------
至少我见过的所有经典j2ee书中都是讲要包含逻辑处理的。
service只是一层wrapper而已，不包含太多的逻辑。
 
 

 Re: 关于BO的问题  发表时间: Jul 24, 2005 12:13 PM   回复 
 
发表人: redlly    发表文章: 42 / 注册时间: 2003-07 
> 至少我见过的所有经典j2ee书中都是讲要包含逻辑处理的。
> service只是一层wrapper而已，不包含太多的逻辑。

我们知道，在特定的领域中，如果不发生革命性的变化，一般来说这个领域的核心数据基本是稳定的。也就是说我们可以抽象出特定领域的稳定数据模型；而在领域中的业务逻辑的变动是比较大的，是难以被固化的。最典型的案例莫过于移动、连通的资费吧，今天一个优惠，明天一个酬宾，业务逻辑可谓是变化五穷，但是它们的基本数据基本还是保持不变，如：资费、时长等等。
这样来说如果在BO中即包含业务对象的属性又包含业务逻辑，在业务需要变动的时候将不可避免的对BO进行修改，更可怕的是，在业务逻辑比较烦多复杂的时候出现包括数十数百个方法，数千上万行代码的巨无霸BO的出现。这跟对象间解耦、分离的理念是严重背离的。

 
 

 Re: 关于BO的问题  发表时间: Jul 24, 2005 12:21 PM   回复 
 
发表人: redlly    发表文章: 42 / 注册时间: 2003-07 
对于SOA（基于服务的架构），我也查过不少资料，包括M$、IBM、BEA等等。但是给我的感觉是SOA只是一种理念，好像并没有一个统一的标准，或者说没有一个可以拿来做实例的案例架构，不像OO、DAO等设计模式。大多数厂商的对SOA的解释也不同、解决方案更是像在做广告，让人越看越迷糊。谁能详细的阐述一下SOA，或者用几句话概括一下SOA。
 
 

 Re: 关于BO的问题  发表时间: Jul 24, 2005 12:42 PM   回复 
 
发表人: banq    发表文章: 5226 / 来　　自: 上海 / 注册时间: 2002-08 
SOA有两者含义：一种是你说的SUN等公司提出那种理念，这更多是一种商业概念；还有一种是J2EE的开发模式的概念，见老外这篇文章可能符合我们这个话题的讨论：
http://dotavery.com/blog/archive/2004/01/04/215.aspx
在这个话题中，SOA就是将Model中的业务逻辑分离出来，单独形成一个服务，我们编程时就是面向这些服务编程了，当然原理的模型因为被抽取主要行为，变成了贫血模型了；但是我认为这符合GOF的桥模式。所以SOA并不是一种反设计的架构。

 
 

 Re: 关于BO的问题  发表时间: Jul 26, 2005 2:34 PM   回复 
 
发表人: flyinair2000    发表文章: 10 / 注册时间: 2004-08 
有很多时候，并不是不能用OO解决问题，而是我们没有能力应用OO而已。
至少，对于你讲的资费问题，并不是没有OO的解决办法。
加上一个service layer，并没有自动解决系统解耦问题，（相反增加了耦合程度。为什么？我也不想说了。－－知道的自然知道，不知道的争论半天，也不会有什么结果。国内论坛，抬杠骂架的居多，不想多说）
只是给一个原始的procedural　programming 加上一个漂亮的wrapper而已。

总之，各人仁者见仁，智者见智吧。
 
 

 Re: 关于BO的问题  发表时间: Jul 29, 2005 11:08 AM   回复 
 
发表人: redlly    发表文章: 42 / 注册时间: 2003-07 
看了不少资料，关于BO（bussiness object）有不少种概念，主要有如下三种：
1、只包含业务对象的属性；
2、只包含业务方法；
3、两者都包含。
呵呵，看起来是仁者见仁了。bang的看法应该是第一种，如果是这样我还是比较偏向于bang的看法。其实怎么定义并不重要，这些东西原本就已经在各种项目、各种模式中存在，只是叫法不同。重要的是要找到一种适合自己项目的模式。
 
 

 Re: 关于BO的问题  发表时间: Aug 25, 2005 6:52 PM   回复 
 
发表人: billywxy    发表文章: 14 / 注册时间: 2003-11 
看了不少资料，关于BO（bussiness object）有不少种概念，主要有如下三种：
1、只包含业务对象的属性；
2、只包含业务方法；
3、两者都包含。

我一直使用第三种
 
 

 Re: 关于BO的问题  发表时间: Sep 9, 2005 8:02 AM   回复 
 
发表人: Kyle_Yin    发表文章: 26 / 注册时间: 2005-09 
"加上一个service layer，并没有自动解决系统解耦问题"-----所以会有ESB一类的东西, 呵呵.

关于SOA, 推荐一个网站 www.soacentral.com, 这是BEA, 微软发起的一个consortium. 上面有SOA蓝图和BEA, J2EE 和微软的参考实现.

SOA和OO不是一个层面的东西. OO的适用范围是偏向系统底层的, 比如编程, 构件设计. SOA是偏向宏观的, 比如集成, 整合, 工作流.

SOA的一个成型的例子是WSRP. 这里的SERVICE是一个PORTLET, 而服务客户是PORTAL. 与传统PORTAL不同的是这个PORTLET不是本地的, 而是基于WEB SERVICES的, 并且可以通过ESB解偶. 当然, WSRP有它的特殊性, 因为整合的地点是在最终用户面前, 呵呵.
 
 

 Re: 关于BO的问题  发表时间: Aug 15, 2005 11:14 AM   回复 
 
发表人: kylix_xp    发表文章: 1 / 注册时间: 2005-08 

我觉得这不是个问题,bo没有了操作方法,还叫面向对象?比如说银行帐号Account对象,存款deposit(),取款withdraw()操作不属于Account对象，难道还属于别的对象？这不是很自然吗？
见 RUP统一软件过程
http://www-128.ibm.com/developerworks/cn/rational/rationaledge/content/mar05/5383/?ca=dwcn-newsletter-rational#N10098

 

对每个用例

建立一个用例实现

补充用例描述（如果需要的话）

从用例行为中，找出分析类
如果我们严格按照RUP过程进行，下一步应该是：

把行为分配给分析类
基于以下理由，这一次，我又会对RUP过程做一点小的改动：回顾一下我们的进展。我们刚刚找到了8个实体类，我们认为这些都是我们系统中的类。在我们做下一步之前，我们需要给这8个实体类增加一些内容，来确认他们是类。

有三种基本的方法来充实我们的分析类：

数据驱动的方法

行为驱动的方法，和

职责驱动的方法。

数据驱动的方法对于从事数据库工作，或者从事过程语言编程的人员来说很常见。他们就是用数据和数据之间的关系来认识、描述世界的，因此会首先去寻找类中的数据－一般没有什么标准的方法去寻找类的函数或功能。这看起来不错，[b]但是数据只是工作的一半。实际上， 类的准确定义，包括了数据和对数据进行的操作。[/b]

行为驱动的方法有着双重的成立理由。首先找出类执行的操作，从中决定这些操作涉及的数据中，哪些应该被这个类所拥有。这很棒，但是我们如何确认我们为类找出的操作之间能够保持一致呢？如何区分操作和类，以明确这个操作是属于这个类，但是 其它的操作要属于同一个类，还是其它的类？我们需要某种方法来区分各个操作。这就是职责驱动的方法带给我们的。

职责驱动的方法是自上而下的，从总体的类及其职责的视图开始。首先定义一个类在业务中的“使命”，这个“使命”描述了这个类对外提供的服务。从军事术语上来说，就是责任和策略。操作和数据是战术层面上的（为战略服务的，服从于某些目标、策略的）。 2

一旦我们确定了我们的类的职责，我们就可以设计一个分析类图，来描述类间关系的整体结构。这个结构一般都是由业务领域决定的。一个UML分析类图可以帮助我们可视化的把这个关系的结构表示出来。

因此，我建议对标准的RUP过程做如下修改（次序的改变）：粗体）：

对每个分析类

描述类的职责

在分析类图上，建立分析类间的联系

把行为指定给分析类（找出操作）

描述每个类的属性和关系

定义类的属性

描述分析类间事件的相关性
u][b][/b][b][/b]
 
 

 Re: 关于BO的问题  发表时间: Aug 16, 2005 6:40 PM   回复 
 
发表人: 大愚弱智    发表文章: 7 / 注册时间: 2004-09 
BO中包含业务对象的属性以及等操作，而业务逻辑由专门的业务逻辑对象处理－－我除了觉得这样做很合理外，甚至还建议把Retrieve，Update，Create，Delete等操作也放到专门的业务逻辑的bean来处理。

把BO当成一个参数传给专门的业务逻辑的bean，把操作和属性分开也见得违反了OO。
专门的业务逻辑的bean一般由容器管理它的状态，这些bean可能还需要容器管理的事务，假如把属性糅合进去也给容器管理好像就不是很适合了。
 
 

 Re: 关于BO的问题  发表时间: Sep 9, 2005 10:24 AM   回复 
 
发表人: Kyle_Yin    发表文章: 26 / 注册时间: 2005-09 
个人意见, 大家对待J2EE模式有的时候太教条了.
切莫忘记很多J2EE模式是在历史背景和特定语境下产生的. 比如: EJB1.1没有"local interface", 早期的容器又缺少对remote EJB界面的优化, 和早期EJB设计者对于客户端多样性的一些设想.

EJB的初衷是纯粹的构建在RMI上的"地点透明". 这个美好的初衷的前提假设是多样化的客户端类型, 比如 HTML, 独立Swing client, Applet client, Midlet client. EJB1 就建立在这个假设之上. 可是很快大家意识到:
1. 这样做的代价是无区别无止境的marshalling, 从而导致性能恶化.
2. 绝大部分J2EE应用是WEB应用, 而WEB 容器和EJB容器通常在一个JVM之内. 没有必要Marshalling.
3. Swing client, Applet, Midlet和其他客户端可以通过其他途径呼叫EJB, 比如WEB SERVICES, 而没有必要用RMI. 事实上RMI-IIOP往往无法通过放火墙, 而SOAP-HTTP则没有这个问题. 对于广域分布应用, web services比RMI更适合做传输手段. 而WEB SERVICES又是可以部署在WEB容器上的, 和EJB同在一个JVM内.
4. 容器生产者往往采用一些优化措施省略不必要的marshalling. 比如在weblogic上, 即使使用了remote EJB, 如果这个ejb部署在本地(JVM), 那么呼叫操作是不通过Socket进行的, 事实上等同于后来的local interface.

在这些发现的指导下, 第一代"核心J2EE设计模式"的主要目的是抵消EJB1的缺点. 比如 Session Facade, Transfer Object的主要目的在于粗糙通信粒度, 减少 Socket 和 marshalling. 而EJB2标准进一步引入了"local interface". 容器生产商也推荐开发者使用这些模式. 自此, EJB 层 与 WEB 层的"共同部署"作为J2EE模式的核心, 成了天经地义.

问题是: 如果WEB LAYER和BUSINESS LAYER"共同部署"在一个JVM里, 那EJB除了"事物处理"和"容器管理永久化"之外, 还有什么意义?

于是产生了SPRING, 于是产生了HIBERNATE. 在TomCat + Struts + Spring + hibernate的领域里, "Business Tier" 成为一个纯粹的设计概念, 不再具备"物理部署"层面的含义.

可是有些传统J2EE的模式保留了下来. 在一个单JVM系统里: Session Facade 和 Transfer Object 已经不具备性能上的必要性, 而更多地是一个审美取向和习惯做法. 当然, Session Facade作为事物处理的起点(spring)的意义仍然存在.

说这么多废话的意思, 是有时我们容易忘记, 分离"状态"和"方法"的"模式", 是为了一个理由而存在的. 在回答"BO"该不该具备"方法"或者"状态"的时候, 我们似乎更应该关心下面的这些问题:

1. 这个BO是代表"交易事物"的, 还是具有"实体身份"的?
2. 这个BO的界面具备什么语意? 有状态? 无状态?
3. 这个BO和下面的永久层什么界面? 如何绑定?
4. 这个BO的部署有什么物理约束?
5. 这个BO现在和未来的客户端是什么, 在哪里?

个人看法, 对于多数中小型, 单层JVM (横向可以集群, 但是纵向"共同部署"在一个JVM里), WEB表达层和EJB业务层"共同部署"的应用而言, 一个完全作为"业务交易中间数据属性集合"而不具备"业务逻辑方法"的BO属于杀鸡的钝牛刀. 原因如下:

1. 没有必要剥离"状态"和方法. "业务逻辑对象"的客户在这个环境里肯定是同一个JVM里, 作为WEB代理的的"SessionFacade", 作为Service代理的ApplicationService, 或者其他复合BO. 在"共同部署"前提下, 它们与BO之间的通信是纯JAVA方法调用. 从性能角度分析, 不必用"无状态"的设计原则来优化通信粒度. 事实上, Core J2EE Pattern里BO的第一个战略"composite entity strategy"也推荐使用 local entity bean 实现BO.

2. 从降低偶合角度看, 复杂数据结构而不具备相应逻辑方法的对象是难以使用的. 可以想象, "业务逻辑对象"的客户程序将需要复杂的代码来维护这个BO的数据完整性. 这样的设计极大地增加了客户程序和业务逻辑对象之间的偶合度.
相反, 如果BO和业务逻辑对象合而为一, 那么BO本身可以负责自身属性数据的检验. 比如, 可以用有限状态模式来设计BO, 既增加BO界面的一致性, 也降低客户程序的复杂度.

EJB3, AJAX, XAML, XUL, 还有其他平台和客户端技术的出现, 应该让我们不断质疑和反思现在"传统"和"模式". 跟随"模式"是不可能有创新的.

 
 

 Re: 关于BO的问题  发表时间: Oct 14, 2005 4:14 PM   回复 
 
发表人: windfromsky    发表文章: 2 / 注册时间: 2005-10 
用文件系统来比方一下:
BusinessObject是程序比如Word程序, 包含业务逻辑
DbObject 是文件, 只包含属性
DbObjectManager 是资源管理器, 管理DbObject

delete,list的操作应该属于DbObjectManager
insert,load,update以及其他业务逻辑应该属于Word程序即BO