DTO pattern vs Memento pattern

They serve different purposes. DTO is a design pattern used to transfer objects between layers and/or tiers of a software application. Memento on the other hand is another design pattern that allows an object to provide an undo capability by externalizing its state which can later be restored if need be. A DTO class and a Memento class for a class may look similar, plain old {Insert Technology Here} object - PO?O or look exactly the same. However, they need to be kept separate because they will serve different needs and therefore evolve differently. For example, you may one day need to include a property in your DTO class but the same property is not important for the object's state management and therefore does not need to be added to the memento class.

Another aspect is that DTO usually takes place outside of your classes and your classes has no idea as they should about DTO. In fact, there are frameworks out there that take care of data mapping for you. For memento pattern on the other hand, your classes will need to provide an api like you see in the uml diagrams such as CreateMemento, RestoreFromMemento etc.

I need do some transfers of model objects from presenters to view(seems like DTO). Also, i need save my models objects into disc(seems like memento). What troubles can i get if i'll decide that same classes would implement DTO/Memento functionality?

Stas 2010-10-27 18:56:35

I would not have them be the same - I would have the memento classes act on the DTO classes. The DTO class's job is to contain data - the memento class's job is to keep track of CHANGES to that data, and then allow you to revert those changes as you need to. The classic example of memento is undo/redo, or transactional based systems. We have a case where we needed transactions on DTOs that were not in a database, and we built an external memento system around it. I would highly recommend following that to help keep your concerns separated.

aperkins 2010-10-27 18:59:49

To put this another way, and make sure I am being clear, you want the two classes to stay separate because they have different responsibilities. Each class should have one responsibility. The DTO's responsibility is to carry data in a single package. The Memento's responsibility is to keep track of change and allow for reverting as necessary. Hope that helps clarify.

aperkins 2010-10-27 19:10:09

Ok. I think your recommendation are right. Also, I need implement undo/redo too. But I think these implementation would be with out memento.

Stas 2010-10-27 19:15:26

@aperkins : Thanks a lot.

Stas 2010-10-27 19:17:17

@Stas no problem. I would recommend looking at the Java Undo-Redo framework (assuming you are using java from your tags), as it handles a large portion of the memento management for you.

aperkins 2010-10-27 19:20:08

@aperkins : I think i'll use some stacks for undo/redo commands. But if you know some good framework i want go throw it)

Stas 2010-10-27 19:24:23

I have built an undo/redo system a few times in Java now, and the Java undo/redo framework (technically it is part of the Swing packages) seems to work really well. It has a simple interface, and some simple management of the system - in other words, it handles all the stack stuff for you :)

aperkins 2010-10-27 19:30:21

@aperkins : Thanks. But, unfortunately, I doesnt use Swing in these project.

Stas 2010-10-27 19:46:42

@Stas it is in the swing packages, but does not have any of the Swing UI components - much like the TreeModel is in the package, but can be used entirely external to Swing itself.

aperkins 2010-10-28 15:07:49

@aperkins : Ok. I'll try it) Thanks one more time)

Stas 2010-10-28 16:57:02

ansaurus

tags:

views:

answers:

DTO pattern vs Memento pattern

related questions