关于hibernate里BO和POJO的问题

在POJO里加方法, 使之成为BO

> > -----Original Message-----
> > From: hibernate-devel-admin@lists.sourceforge.net
> > [mailto:hibernate-devel-admin@lists.sourceforge.net]On Behalf
> > Of Miguel
> > Henley
> > Sent: Tuesday, October 28, 2003 1:07 PM
> > To: hibernate-devel@lists.sourceforge.net
> > Subject: [Hibernate] Business Rules
> >
> >
> >
> > Hi all,
> >
> > Please, take a look at the the following scenario:
> > A "Order" persistence class is associate to a "Customer"
> > persistence class and the business rules is:
> > We can not make a new Order if the Customer associated with
> > that Order has some credit restrictions.
> >
> > Where is the right place to put this rule is Hibernate ?
> > At a Interceptor class ? At the Order class (using the
> > validate() method of the Validatable interface) ?
> >
> > Regards,
> > Miguel.
> >

From: "Eric Pugh" <epugh@upstate.com>
To: "'Miguel Henley'" <miguel@huycknortelas.com.br> <hibernate-devel@lists.sourceforge.net>
Sent: Tuesday, October 28, 2003 7:38 PM
Subject: RE: [Hibernate] Business Rules


> I lean towards not putting that kind of logic in some sort of Manager
> object.. I find that when you start mixing busienss logic with data
> objects, soon your business logic tier and data tier become all intertwined.
>
>
> I would lean towards OrderManager or something where you have a call like:
> OrderManager.createOrder(Customer) throws OrderCreationException or
> OrderManager.canCreateOrder(Customer)
>
> Then put that business logic about credit restrictions into the
> OrderManager.. Because over time your Customer and Order objects will
> remain the same, but your business rules on credit restrictions may change!
>
> Eric

> So, do you think that for each persitence class it's a good design decision to create a Manager class ? The Manager class first check the business rules and if it's Ok calls the save / update / delete methods of the session. Is it right ?

No, this is not a good design decision. Your domain model classes should implement the business rules and functions. Some of them might be persistent, but thats what you have Hibernate for. Sometimes you might use a "Manager" type class in your domain model, but most of the time the objects _themselves_ interact by calling business methods on each
other and/or passing themselves as arguments.

Read up on "Strategy Pattern" and other techniques how to implement this. A good source is Martin Fowler's Patterns of Enterprise Architecture, but it's not "only" about domain model/transaction scripts/business logic design issues.

--
Christian Bauer
christian@hibernate.org

主要还是代码清晰问题  

  我的上一个项目，就是采取Manager类的方式的。
也就是说Manager类完成大部分的商业逻辑。（其实是JSP ...不怕大家笑话，但是jsp有个好特点，就是改程序不需要重启）。

我还在另一个项目中采取这样的方法：
DAO类（或者hibernate的POJO类）作为基类，再做一个子类，称为Logic类。把逻辑写在Logic类中。
这样的好处是，这个DAO/POJO很可能是由某个生成器生成的，那么在修改的时候就比较简单，重新生成即可。

这样的坏处就是在Hibernate的mapping文件中，或者其他获得valueObject的home方法中，都比许有个机制来返回子类而非父类。Hibernate本身倒也是支持。

不知道大家的看法如何？ 

我的想法
...
然后用session bean或一般POJO写业务. 在业务类里创建一个People_DTO对象作为DTO, 赋People_BO的植给他. 把People_DTO传给表示层修改. 然后用People_DTO修改People_BO.
再用People_DAO去把People_BO的值放到数据库里.

感觉这里有点复杂。
有没有想过，这里的POJO其实已经失去实例化的意义？
我设想另外一种可能：这个POJO作为一个interface实现，那么所有的instance实际上都只有一种:就是People_BO。
事情会变得简单的多。

我也有过用BO做DTO的想法, 但考虑到BO里可能有不少方法或程序用的成员变量. 用新的DTO清晰一点, 对网络负载也小. DTO和BO的互赋值很简单, clone就可以了. DAO是一定要的. 这样才可把data access logic 和business logic分开