Re: Design question with Struts
Hi Brian, On Thu, 23 Oct 2003 20:51:21 -0400, [EMAIL PROTECTED] wrote: (snipped) 1) A Cache implementation that only provides java object identity ( = ) within a single transaction boundary. I am not sure how this would work, may have to hack around some. Cache might clone the object and return the clone within transactional boundaries, but I am not sure the cache can detect transactions. Maybe use cglib to return a derived proxy that handles things. Hmmm. Must go poke when I have a chance. Isn't that what ObjectCachePerBrokerImpl does? I believe it clears the cache whenever a PB instance is closed, which happens when a transaction (ODMG at least) is committed or aborted. I was also thinking of relying on this to safely pass domain object out to clients. Cheers, Gerhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design question with Struts
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 24 October 2003 10:54 a.m. To: [EMAIL PROTECTED] Subject: Re: Design question with Struts The Command is designed so that any object in the domain model that it modifies is populated into the response as a transfer object (really it is the domain object, but once it is outside transaction context of OJB it is no longer live so is safe to pass back to clients). These are used by Struts to render stuff. Hi Brian Can I check if I correctly understand what you have said here ... you would never have a modified domain object that has yet to be persisted? IOW your command modifies and persists the domain object in one hit?? Before I ask or comment more I will wait to see if I understand you correctly ;-) Saves typing and misunderstanding (I hope *grin*) Cheers Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question with Struts
Shane, In this particular application, yes that is exactly what it does. I don't need any modifications that span multiple requests in this particular app. The client application (ie, the web application) isn't allowed to hold onto live domain objects. If need be it can hold onto a transaction with a series of modifications, but then you wind up holding a lot of transactional state around in some type of session (be it a stateful session bean, http session, etc). I have modified domain objects that are not yet persisted all the time - right before they are persisted =) Some of the commands are pretty complex (despite it being a simple application -- it does some fun stuff trying to model human/group relations that has not yet been exposed to the UI) and build quite a bit of domain information before persisting any of it. Right now commands in that particular application are all atomic, however. If I needed to have a long-lived transaction in this application (ie, create and modify a domain object via multiple hits) I would probably design it around capturing the changes in an OTM Transaction and giving the client a transaction token in order to associate the new changes with the previous transaction) -- the domain model is still only live within the core application upon which the other apps are just clients with some interface to twiddle it. This type of system doesn't work for everything, but it does for a lot I have found. Large scale GIS systems I am pretty confident it wouldn't work well in, for instance. Does that clear up what I described? -Brian ps: sorry for not quoting, I am at NFJS Atlanta and working through a pita webmail client - This mail sent through IMP: http://horde.org/imp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT]RE: Design question with Struts
Quoting Shane Mingins [EMAIL PROTECTED]: ... have been reading Core J2EE Patterns and Patterns of Enterprise Application Architecture. btw - if you find those books useful I must highly reccomend _Domain- Drive_Design_ by Eric Evans. It is another annoying-expensive hardback design books but it *really* looks at domain design hard and is quite solid. Core J2EE and PEAA sort of mention domain models as good things but never go into building a good one. They both focus a great deal on layer-interface issues (which are big issues) compared to model design, which is the core of any good application. Anyway, will hush up now as I don't get commissions =) -Brian - This mail sent through IMP: http://horde.org/imp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
