the scenario you sketched is right. The order is persisted and some orderlines also. The point is, when I click the 'add line' or 'remove line', a request cycle is executed, the LoadableDetachableModel is loaded, items are removed and/or added and I have to commit that to the database. Or where do I keep those changes until I'm finally finished? Must cases are simply indeed, but I have some really complex edit scenario's that takes really time from the user, and I want to give them the possibillity to back out in case they rethink. It's a realworld scenario.
Or am I really thinking to difficult? Remember: I don't want to fall back to DTO's. (I'm still at the point trying to avoid DTO's at all cost, but that's another question). 2008/2/14, James Carman <[EMAIL PROTECTED]>: > > I don't know that the Memento design pattern will necessarily solve > the problem you're talking about. So, you have a persistent Order > entity object in your application (is the order saved to the db > already)? And you want to add OrderLine objects (also persistent) to > it, but you don't want that persisted to the database? Sure, you can > take a memento of the Order from before you started adding/removing > stuff, but won't the adds/removes actually get persisted? If they > aren't, then why do you need the memento in the first place? You can > just reload the object from the database if you want to get back to > its pre-edit state? > > > On 2/14/08, Martijn Lindhout <[EMAIL PROTECTED]> wrote: > > Hi Nick, > > > > I prefer the same approach as you, because my domain model is rich and > gives > > me direct feedback of what goes wrong when somebody wants to change the > > model state. This works well for editing simple domain objects, but one > of > > the challenges I'm facing now is: how do I implement multiaction edits > that > > are not directly propagated to the database? Again I take the good old > > Order/OrderLine example, where I want to add and remove lines at will, > and > > finally commit them in the DB (or let the user cancel it). I asked a > similar > > question a few days ago, and someone suggests using the Memento > pattern, > > which I'm implementing now. > > > > My question to you is: how do you approach this scenario? > > > > 2008/2/14, Nick Heudecker <[EMAIL PROTECTED]>: > > > > > > > > I always use business objects as my model objects unless the data is > some > > > form of aggregate, like a summary table. > > > > > > > > > > > > > -- > > Martijn Lindhout > > JointEffort IT Services > > http://www.jointeffort.nl > > [EMAIL PROTECTED] > > +31 (0)6 18 47 25 29 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Martijn Lindhout JointEffort IT Services http://www.jointeffort.nl [EMAIL PROTECTED] +31 (0)6 18 47 25 29
