关于BO的问题

redlly

我们在开发系统时,一般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等操作，而业务逻辑由专门的业务逻辑对象处理？
banq 2005-07-17 07:55
你的疑问正好和这篇文章讨论的一致：

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，会产生什么样后果。也许“教皇”不是凡人，比你我看得很远，可惜我是倡导“上帝死了”的人。

redlly 2005-07-18 12:46
SOA好象是基于服务的架构,能说说和这个具体有什么关系吗?
flyinair2000 2005-07-23 11:01
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为代表的方面编程了。

flyinair2000 2005-07-23 11:07
或者是BO只包含业务对象的属性，对BO的所有操作都由业务逻辑对象处理？

至少我见过的所有经典j2ee书中都是讲要包含逻辑处理的。
service只是一层wrapper而已，不包含太多的逻辑。
redlly 2005-07-24 12:13
> 至少我见过的所有经典j2ee书中都是讲要包含逻辑处理的。
> service只是一层wrapper而已，不包含太多的逻辑。

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

redlly 2005-07-24 12:21
对于SOA（基于服务的架构），我也查过不少资料，包括M$、IBM、BEA等等。但是给我的感觉是SOA只是一种理念，好像并没有一个统一的标准，或者说没有一个可以拿来做实例的案例架构，不像OO、DAO等设计模式。大多数厂商的对SOA的解释也不同、解决方案更是像在做广告，让人越看越迷糊。谁能详细的阐述一下SOA，或者用几句话概括一下SOA。
banq 2005-07-24 12:42
SOA有两者含义：一种是你说的SUN等公司提出那种理念，这更多是一种商业概念；还有一种是J2EE的开发模式的概念，见老外这篇文章可能符合我们这个话题的讨论：
http://dotavery.com/blog/archive/2004/01/04/215.aspx
在这个话题中，SOA就是将Model中的业务逻辑分离出来，单独形成一个服务，我们编程时就是面向这些服务编程了，当然原理的模型因为被抽取主要行为，变成了贫血模型了；但是我认为这符合GOF的桥模式。所以SOA并不是一种反设计的架构。
flyinair2000 2005-07-26 14:34
有很多时候，并不是不能用OO解决问题，而是我们没有能力应用OO而已。
至少，对于你讲的资费问题，并不是没有OO的解决办法。
加上一个service layer，并没有自动解决系统解耦问题，（相反增加了耦合程度。为什么？我也不想说了。－－知道的自然知道，不知道的争论半天，也不会有什么结果。国内论坛，抬杠骂架的居多，不想多说）
只是给一个原始的procedural　programming 加上一个漂亮的wrapper而已。

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

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

我觉得这不是个问题,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个实体类增加一些内容，来确认他们是类。

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

数据驱动的方法


行为驱动的方法，和


职责驱动的方法。


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

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

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

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

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

对每个分析类


描述类的职责


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


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


描述每个类的属性和关系


定义类的属性


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

大愚弱智 2005-08-16 18:40
BO中包含业务对象的属性以及等操作，而业务逻辑由专门的业务逻辑对象处理－－我除了觉得这样做很合理外，甚至还建议把Retrieve，Update，Create，Delete等操作也放到专门的业务逻辑的bean来处理。

把BO当成一个参数传给专门的业务逻辑的bean，把操作和属性分开也见得违反了OO。
专门的业务逻辑的bean一般由容器管理它的状态，这些bean可能还需要容器管理的事务，假如把属性糅合进去也给容器管理好像就不是很适合了。
billywxy 2005-08-25 18:52
看了不少资料，关于BO（bussiness object）有不少种概念，主要有如下三种：
1、只包含业务对象的属性；
2、只包含业务方法；
3、两者都包含。


我一直使用第三种

Kyle_Yin 2005-09-09 08:02
"加上一个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有它的特殊性, 因为整合的地点是在最终用户面前, 呵呵.

Kyle_Yin 2005-09-09 08:30
"这根本不是感觉的话，这样的模型又回到了procedural programming的老路上了。"

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

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

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