I see the following two options: 1) Make the constructor on Order private and use a static factory method on Order to first verify the Customer does not have credit restrictions before creating the Order.
2) Make the constructor on Order package level access and add a method to Customer to create an Order. Put the credit restriction check there. This assumes it makes sense to have Customer and Order in the same package. I would avoid putting the logic in a validate() method. If the rule is that an order cannot be created for a customer with credit restrictions, you should never create an Order object that breaks that rule. Regards, John Urberg There are two types of programming languages; the ones that people bitch about and the ones that no one uses. - Bjarne Stroustrup -----Original Message----- From: Miguel Henley [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2003 6:07 AM 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
