This particular application (tiny, not used much, never will be, and was written in a hurry and not by me) implementing it after the fact ain't going to happen. Not worth the cost to the customer.
In general though, youre quite correct (and I'm cutting through the layers of abstraction. Ultimately Actions do result in things happening. Your C refers to the M at some point. I have no doubts I should be more anal on this subject though, so maybe I should ask this question. To me a WebApp request typically has a nice predefined unit of work for the database. That is, usually you want the request to begin a transaction early and either commit or rollback at the end. But SOMETHING has to know when to begin a database transaction and decide to roll it back or not. The business objects won't necessarily. Your first method call may need to be rolled back after the fact and it can't know what happens later... So where's the best place to manage that? (I suspect an obvious and better answer than mine will be given to me en masse after I hit send) Since Struts knows when that request begins and ends, I use it to handle it. I have it talk to my persistence layer (not necessarily Hibernate. I didn't couple myself to it here, there's an encapsulation going on) to do initialization and cleanup in a request processor. Sounds like you prefer option 2. If it's stashed in a ThreadLocal with a static Accessor. It never winds up in the web tier at all, even if generated in the Request Processor. The actions NEVER see it at all... > Just before I go to bed after a long work day: what the heck has > Hibernate or any other Resource Tier means to do with the > presentation layer (Struts)? Hibernate is just for Persistence, > with the details usually isolated from the web tier by (usually > several) additional layers (DAO, Services, Business Delegate > and so on). Hibernate lives in the backend, business logic > comes somewhere on top of that, and the web tier (and Struts > is part of and limited to that) is for presentation purposes > only. If you start to care about Hibernate Sessions in the web > part, you should possibly rethink your architecture. > > -- Chris. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
