关于BO的问题


我们在开发系统时,一般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等操作,而业务逻辑由专门的业务逻辑对象处理?

你的疑问正好和这篇文章讨论的一致:

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

SOA好象是基于服务的架构,能说说和这个具体有什么关系吗?

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为代表的方面编程了。

或者是BO只包含业务对象的属性,对BO的所有操作都由业务逻辑对象处理?
------------
至少我见过的所有经典j2ee书中都是讲要包含逻辑处理的。
service只是一层wrapper而已,不包含太多的逻辑。

> 至少我见过的所有经典j2ee书中都是讲要包含逻辑处理的。
> service只是一层wrapper而已,不包含太多的逻辑。

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

对于SOA(基于服务的架构),我也查过不少资料,包括M$、IBM、BEA等等。但是给我的感觉是SOA只是一种理念,好像并没有一个统一的标准,或者说没有一个可以拿来做实例的案例架构,不像OO、DAO等设计模式。大多数厂商的对SOA的解释也不同、解决方案更是像在做广告,让人越看越迷糊。谁能详细的阐述一下SOA,或者用几句话概括一下SOA。

SOA有两者含义:一种是你说的SUN等公司提出那种理念,这更多是一种商业概念;还有一种是J2EE的开发模式的概念,见老外这篇文章可能符合我们这个话题的讨论:
http://dotavery.com/blog/archive/2004/01/04/215.aspx
在这个话题中,SOA就是将Model中的业务逻辑分离出来,单独形成一个服务,我们编程时就是面向这些服务编程了,当然原理的模型因为被抽取主要行为,变成了贫血模型了;但是我认为这符合GOF的桥模式。所以SOA并不是一种反设计的架构。

有很多时候,并不是不能用OO解决问题,而是我们没有能力应用OO而已。
至少,对于你讲的资费问题,并不是没有OO的解决办法。
加上一个service layer,并没有自动解决系统解耦问题,(相反增加了耦合程度。为什么?我也不想说了。--知道的自然知道,不知道的争论半天,也不会有什么结果。国内论坛,抬杠骂架的居多,不想多说)
只是给一个原始的procedural programming 加上一个漂亮的wrapper而已。

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

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


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

对每个用例


建立一个用例实现


补充用例描述(如果需要的话)


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

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

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

数据驱动的方法


行为驱动的方法,和


职责驱动的方法。


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

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

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

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

因此,我建议对标准的RUP过程做如下修改(次序的改变):粗体):

对每个分析类


描述类的职责


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


把行为指定给分析类(找出操作)


描述每个类的属性和关系


定义类的属性


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

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

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

看了不少资料,关于BO(bussiness object)有不少种概念,主要有如下三种:
1、只包含业务对象的属性;
2、只包含业务方法;
3、两者都包含。


我一直使用第三种

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

"这根本不是感觉的话,这样的模型又回到了procedural programming的老路上了。"

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

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

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