如何自动备份删除的对象（1）
?? 应用和Framework最大的不同在于写Framework都是你在提要求，应用中则有那些让你猛然一惊的需求，即所谓“业务特点”，你还真都得去满足。比如下面这个：
?????? 对于系统里的重要对象，要能够看删除记录，知道是谁删的，删了什么。
????? 设系统中有一个Order对象
class Order { long oid; String orderNo; List<OrderItem> items; User creator; Date createTime; // ... getter, setter}?????? 这个需求是说，为避免纠纷，对于被删除的Order，要能够根据orderNo，删除时间等作查询，并能够查看Order被删除时的样子。一般这种功能不会开放给用户，但后台管理总会有这样的需要。
?
???? 好了，问题清楚了。那么我们该怎么作呢？
???? 第一种方法最直接。假设Order和OrderItem分别存在 m_order表和m_order_item中，这种方法需要建立b_order和b_order_item表，并为需要删除的Order和OrderItem各创建一个子类
class DeletedItem extends Item{};class DeletedOrder extends Order{ private List<DeletedItem> items; @Override public List<Item> getItems{ return this.items; } }????? 这样， Service在删除一个Order对象时，只需要new 并register 一个DeletedOrder就好了
?
void deleteOrder(Order order){ DeletedOrder delOrder=new DeletedOrder(); delOrder=getBaseDto.register(delOrder); delOrder.setOrderNo(order.getOrderNo()); // ... deep clone order to delOrder; }??? 这种方案，对于DeletedOrder采用了单独一张表，查询也没有问题。
?? 那么，这个方案的可行性怎么样呢？不怎么样！
? 1）DeletedOrder映射为一张物理表的方案，意味着对N个要查询删除的对象，系统中要建立N张表，这有很大的维护开销。如果以后Order结构变化，则m_order和b_order表都要按照相同的schema更改，开销更大。为这么点破事就搞出这么多表来，这种设计太重。
? 2）假设系统中有N种要查询删除的对象，这个方法需要service写N段分散的代码。想要知道一个对象是否会被备份，只有一个个查看引用，这种设计不符合开闭原则。
?? 针对以上两个缺点，一个最终的方案应该包括以下两个特点
?? 1）最好数据库中一张表能搞定
?? 2）对于Service层透明，维护时要阅读和修改的代码尽量少，责任明确。
?
?
?