生成数据库模式
尽管我的第一印象是所有内容都来自映射文档，但是Hibernate Synchronizer目前不支持从映射文档创建或更新数据库模式。支持论坛上已经提出了相关的请求，所以如果将来看到这些特性，我肯定不会吃惊，因为提供这类支持并不很困难。目前来说，如果要从映射文档开发数据库，就必须使用像Hibernate: A Developer's Notebook书中这种Ant驱动之类的方法。此外，下面描述的Hibernator插件支持在Eclipse中进行模式更新。我可能要研究一下是否可以同时安装这两种插件。
我希望本文能够让您清楚地了解该插件所提供的功能。无论如何，我没有涵盖它的所有功能，所以如果您有兴趣，可以去下载它然后自己进行探索。
权衡毫无疑问，可以使用Hibernate Synchronizer来完成一些灵巧的工作。是否要在我自己的Hibernate项目中使用它呢？这样做有优点也有缺点，很可能直到实际采用Hibernate来代替我们正在使用的自己开发的（且过分简单的）轻量级O/R工具时，我才会做出决定。这是一次意义相当重大的改动，而我们把这次改动推迟到了由于其他原因进行架构变换的时候。下面是对我的决定起着重要作用的一些因素。
正如我们在安装小节中所谈到的那样，在许可证方面还存在着一点问题。插件的论坛中有此方面的讨论。当前的许可证基于对GNU GPL的定制修改，这次修改删除了所有源代码共享方面的条款，但是试图保留“copyleft”保护的其他方面。关于这样做的合法性仍然存在一些问题，而作者正在寻求另一种解决办法。很清楚，目的是要保护插件，而不是阻止其他任何项目使用该插件生成代码，但是有必要仔细阅读当前的许可证，看一看其目的是否已经达到，或者您是否仍然冒着很大的风险。
同一讨论表明，作者原来是以开源的形式发布插件的，但是又临时收回了这一决定，因为他觉得它还不够完美以用作一个优秀的范例。接着，他与一些莽撞的人通过一些非常不愉快的邮件，这使他不愿再共享源代码。当然，他有权决定是否与我们共享源代码。该插件对于整个世界来说是一份大礼，而作者并不欠我们什么。但是我希望他能与其他用户进行足够的正面交流，这样就能坚定他原来共享源代码的想法。我真的认为能够看到我使用的工具的源代码是一件很有价值的事情，不仅因为这是一个很好的学习机会，还因为这意味着，如果需要的话我可以立刻修复一些小问题。作者在解决用户的问题方面始终很热心，响应也很快，但是一个人无法维持一个社区，因为我们都有繁忙、筋疲力尽和心烦意乱的时候。
Hibernate Synchronizer使用它自己的模板和机制来生成数据访问类，这既有优点也有缺点。优点是可以获得比Hibernate的“标准”代码生成工具更多的功能。可以使用数据对象的一个自动生成的子类，并在该数据对象中嵌入业务逻辑，而无需担心重新生成访问代码时这些业务逻辑会被改写，这也是一个不错的特性。插件生成的使很多简单的场景更简单的类还提供了其他的优点。
