I am trying to develop a pattern where I am handing out to my Client Tier DataObjects that are read-only, until the Client asked for it to be unlocked.
My thinking is that it will be more efficient to 'lock' down objects that are coming from my O/R layer (cache), as opposed to either cloning them, or creating another Value Object. All this, with the goal of the ClientTier not having the ability to mutate objects that are referenced in a global cache. Since 90% of my hits are going to read-only -- I wanted to defer the process of cloning the cache-references until it is really needed. Obviously, I could add booleans to my DO's and in every set method check to make sure that it isn't a locked object. Instead, it seems to me this is a perfect place for AOP. And it works for the times the application uses the setters. However, we have a util class that will map/populate objects from HTML form postings, using introspection. In that case, the Interceptors are never fired (which makes complete sense). The most obvious solution would be to intercept the Field.set* methods and see if the object it is working on is one of mine, and do my check there. But, I am not sure if there would be a negative ramification to intercepting such methods, considering they are system-level methods, that I am sure AOP is using as well. Thoughts? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3836304#3836304 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3836304 ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
