Most (again I say most; Amazon doesn't) shopping carts die with your session. If you don't place your order and you close your browser, you lose what you've collected thus far. So, you could store your shopping cart (Order) information in your session if that sort of functionality is o.k. with your requirements.
If you wish to persist the Order data between sessions so that a user can come back and continue working on their order, then I'd just put a status on their Order saying that it's "in progress" and then when they submit it, you set its status to "submitted" or something. Then, when someone logs in and tries to add something to their order, you add it to their "in progress" Order object in the database (create one if necessary I would guess). On 2/14/08, Martijn Lindhout <[EMAIL PROTECTED]> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
