lies! all lies! it makes perfect sense to put transactional boundaries on the ui events. user "clicking a button" is an action that the user perceives as being a unit of work which is where the transaction boundary should be.
it is also not uncommon to put transaction boundaries on the request - which is also a ui artifact. dont get me wrong, you should still have transactional boundaries on the domain object, but you should have a higher one on a button.onsubmit() so that it combines whatever transactions the domain calls will start into a single one. just my two cents :) -igor On Fri, Apr 24, 2009 at 7:39 AM, James Carman <[email protected]> wrote: > On Fri, Apr 24, 2009 at 9:07 AM, Andreas Petersson <[email protected]> > wrote: >> 1) be able to use AOP on components (guice). for example use @Transactional >> on onClick method to tightly specify transaction boundaries. > > I wouldn't recommend that. Putting transactional boundaries on user > interface methods is not a good idea, IMHO. If the "stuff" logically > belongs in a transaction, then it should be part of the "domain" > model. The UI would then use the domain model to get to the logic. > This would also make it much easier to unit test the logic. > > --------------------------------------------------------------------- > 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]
