关于BO的问题

05-07-15 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而已,不包含太多的逻辑。

5Go 1 2 3 4 ... 5 下一页