Sorry for the OT, but I need recommendations from a very intelligent group ;-)
I picked up the new Core J2EE Patterns Book [2nd Ed] and it proposes "Business Objects" that act much like POJO Session Beans. But in the scope of a layered architecture, some say we should enforce that our [Domain, Business, Session] objects shouldn't know anything about the persistence mechanism since we are purely providing business logic at that layer. Do I wrap the persistence layer in a procedural-type service layer that meets use-cases? A worked example would be changing the shipping address on an OrderBO and then needing to recalculate the best warehouse based on x-variables. Much of the data isn't provided in the model and would require calls to stored procedures, etc. I was thinking of representing business rules as callback handlers (PropertyChangeListeners)? I agree with the Core J2EE Patterns book in separating your data model and your behavior model [OrderBO wraps OrderDTO]. This allows the application to pull data for views without the overhead of a complex behavior model when it's not needed (Domain Model). What are your opinions on representing business behavior in relation to the persistence layer? On my last project we did a VERY robust domain model, but found that it became very sloppy at efficiently getting data from the database (too much or too little data). Many Thanks! -------- Jacob Hookom Senior Programmer/Analyst McKesson Medical-Surgical Golden Valley, MN --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
