一、基于对象序列化的Undo\Redo
在Rockford Lhotka的CSLA框架中，介绍了一种基于保存序列化对象入栈的Undo\Redo实现方案。调用BeginEdit函数时，通过反射机制将整个业务对象的所有Field序列化，并保存在UndoStack中。在Undo时，将保存在UndoStack中的序列化的Map值读出来，对现有的业务对象进行数值还原。
由于使用对象序列化的方式来保存对象的历史。所以当UndoStack比较深，或是业务对象比较大的时候会占用比较多的内存，性能上也不尽如人意。但是CSLA的Undo实现方式通用性较好。所以适用范围还是不小的。
二、基于Command模式的Undo\Redo
GoF的名著《Design Patterns》中介绍了著名的Command的模式，主要用途之一就是用来实现Undo\Redo的。具体实现方式就不在这里介绍了，有兴趣可以参考《Design Patterns》一书。
灵活运用这种实现方式可以应对各种Undo操作，但是是以损失一定的可复用性为代价的。一个可以Undo的操作越具体，它和实现应用的关系就越紧，抽象性就越差，也就越难以复用。其极端情况就是每个Command都要符合ACID。
最重要的是，如果要使用Command模式来实现Undo机制，最好是在开始写代码之前就做这个决定，并自始至终使用Command来响应用户请求。如果等到所以的代码都写到Click事件处理函数里的时候，再想用Command来实现Undo\Redo就麻烦了。
三、结合RoutedEvent、Observer模式和Command模式的Undo\Redo
为了解决上面两种Undo实现方式的缺点，既保证通用性，又能减少资源占用。可以将上面的两种方式结合起来，并联合和RoutedEvent机制和Observer模式。
RoutedEvent是.NET 3.0中的WPF里的新型的事件传递机制。主要特点是子对象的事件发生后会触发父对象的相应事件。从而简化事件的订阅。但是WPF里的RoutedEvent只能用在UIElement上，业务对象就无福消受了。所以可以自己实现一个简单的RoutedEvent机制来简化事件的订阅。
然后用一个Watcher对象监视业务对象的变化，将变化抽象、封装成一个可以Undo、Redo的Command。大致可以分成PropertyChangedEdition和ItemChangedEdition两种，就可以提供对于属性改变、从List中删除、向List添加、List中Item Move这些常见操作的Undo、Redo了。
当然这种方式也有不好的地方，由于抽象程度比较高，所以这种Undo机制并不能很好地和业务逻辑契合，比如List A和List B的添加、删除是同步且应该被视为一个操作时，这种机制还是认为是两个操作。
上面介绍了两种常见的Undo、Redo的方式和一种新的实现方式，算是抛砖引玉，帮助大家找到更适合自己的Undo Redo实现方式。