Hi. (Jumping in. Hope you don't mind.)
On Mon, Jun 22, 2009, 21:06, CN Yee <[email protected]> wrote >...(example munched)... >The preBind() method pre-loads the customer domain object, where stripes >binding will bind direct to it. The save() method can simply persist the >domain object without having to use a data transfer object and a whole heaps >of codes to copy properties. This is the binding direct to domain object >pattern advocated in >http://www.stripesframework.org/display/stripes/Binding+Into+Domain+Models. Yes. Nice and convenient. >Now let say I want to introduce the following method: > > @After(stages=LifecycleStage.BindingAndValidation) > public void afterBind() { > states = lookupService.getStateCodes(customer.getCountry()); > } > >The method is to load the list of states to populate a dropdown list. Fair >enough use case. Fair enough. >Now consider the user press the 'cancel' button. > >- preBind() loads the domain object >- stripes binding binds the post back values. >- afterBind() kicks in, lookupService got invoked. Now since LookupService >is managed by the Transaction Manager, it is surrounded by open and commit >transaction. Wait. You have a method that just fetches some information from the DB, but, as a side effect, will also commit your current transaction? That sounds like a pretty serious problem to me. And not just for the binding direct to domain pattern--what if you have two changes that you need to make atomically, and the second relies on getting some of that information from the DB? So you do the first set of updates, then do your lookup, and find out that the second update won't work. So now you want to roll everything back. But, no, you can't, because your select query went and committed the first set of updates! >I know I can use @Before(stages=LifecycleStage.BindingAndValidation, >on="!cancel") to get around this problem. I can probably tweak the >Transaction Manager to always open a separate transaction. But after some >days of thinking - it seems to me that there is simply to many ways for >things to go wrong. The binding direct to domain model pattern does not >seems to be tenable. I've been using the binding into the domain model pattern in the project that I'm currently working on. And, yeah, it does make it a bit easier to shoot yourself in the foot. But it also eliminates a ton of busy work. So far, I've found that the time saved on the busy work more than makes up for the time spent being extra careful about inadventent commits (the latter being time well spent, anyway). YMMV, of course. Though I would seriously reconsider allowing your utility lookup methods to commit transactions that they didn't create. -allen ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Stripes-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/stripes-users
