我的通用草稿箱设计--所有表单均可实现自动保存草稿，请大家讨论

我想实现类似于gmail的草稿箱，希望是通用的，如需要则所有表单均可以自动保存，但没想明白草稿数据如何保存，不同的表单表结构千差万别，总不能建许多临时表吧。
我现在想到了一种办法：对象序列化，无论何种表单，在编辑过程中用ajax保存后，创建bean实例保存数据但不映射保存到对应的数据库表，而是序列化后统一保存在一个草稿箱表中，当用户提交表单时，保存数据库同时删除这条草稿，如出现异常，则用户再次登录时可提示恢复，则从库中取出反序列化并填写到表单中展示给用户。
这样无论是什么表单，都可以统一的方式实现了，也只需要一个表就可以了。

还没开始动手实现，请大家讨论，这是不是实现草稿箱的最佳方式？

序列化并不适合长期保存，一旦代码重新编译。。

但那只是实体bean，不太会经常改变的，如果改变，通常是增加新的属性，想想办法也许还能用吧，早期的草稿只是少了几个新属性嘛。

我看没必要那么讲究，把草稿放在 session 中就行，用户登出就自然回收掉了。

我的想法是，一个系统不可能会有很多草稿的，撑死了几千份；直接保存xml好了

可以采用统一的格式来序列化 如xml json

但XML要编程的啊，每种表单不一样要分别处理，不如序列化来得省事，把准备向数据库提交的对象序列化保存就行了。

我在gmail有几十个草稿，懒得清理，如果系统全面支持草稿，数量也不少。

对于传统mvc模式（由展示层输出HTML）下，直接序列化保存对象最省事，在ajax模式下则保存json更好，反正都是前台解析组装数据，恢复时再把json丢过去就行了。

你没理解我的意思

直接保存为JSON或XML，最好是JSON，解析比较高效。在重新载入草稿编辑的时候载入JSON，然后根据不同的情况（字段不同）下的表单，从解析后的JSON中的对应字段找数据，找到就填充，否则就按默认值处理。

我的意见还是：对于传统mvc模式（由展示层输出HTML）下，直接序列化保存对象最省事（XML持久化也行），在ajax模式下则保存json更好，像ispring说的在恢复时把json丢过去就行了。

比较了一下java序列化和XML持久化（XMLEncoder和XMLDecoder），从性能上看，前者性能极佳，后者耗时是前者的3-8倍，越复杂的对象xml持久化越耗时（但仍比数据库快多了，数据库存取一个最简单的表要花序列化30-50倍的时间）。比起使用数据库，这点性能差异可以忽略不计。
XML持久化（XMLEncoder和XMLDecoder）只支持标准的javaBean，对于非标准的属性会丢弃，但也有优点，如果javaBean增加了新的属性重新编译了，原来保存的XML仍然能够正确还原。如果数据是标准的javaBean，用XML持久化是很好的方案。
而序列化在对java类修改并编译后，原来保存的序列化文件无法正确还原。但是序列化的通用性很强，任何实现了序列化接口的对象都可以正确序列和反序列化。

因此这两种方式各有利弊，都可以用，那么序列化文件或XML文件是保存文件系统还是数据库呢？保存文件系统尽管性能好，但不容易组织（有好的文件系统组织方式的资料吗？），还是放在数据库中吧。