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 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf > Of Miguel > Henley > Sent: Tuesday, October 28, 2003 1:07 PM > To: [EMAIL PROTECTED] > 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. > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > hibernate-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
<<attachment: winmail.dat>>
