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]
