我们有一个已经运行了很长时间的应用程序。现在我们将它迁移到Spring，并可能使用Hibernate或任何其他ORM。
但我们赶上了一个问题。对于现有的数据库使用Hibernate并在Schema周围建模对象是不是不推荐/坏主意？
大多数人提倡不使用Hibernate，而不是像iBatis那样使用其他一些ORM。但在我们公司，所有人都是Hibernate的支持者。
有经验吗？
答案 0 :(得分：13)
我会说在不知道你的要求的情况下选择Hibernate，iBatis或其他任何东西都是不负责任的。
如果你没有固体对象模型，我会说Hibernate是一个糟糕的选择。
如果你使用存储过程作为数据库的接口，我会说Hibernate是一个糟糕的选择。
如果您不喜欢Hibernate为您生成的动态SQL，我会说Hibernate是一个糟糕的选择。
得到它？像那些来自Hibernate支持者那样的反感反应并不是一个好主意。
可能是iBatis或Spring JDBC模板比Hibernate更好。你应该对这个决定更加了解，并为你的应用程序做出决定，而不是盲目地听一个暴徒。
你也不必全部或全部。可以使用一种技术实现部分解决方案，将其余部分实现在另一种技术中。
我建议您使用基于接口的持久层，以便在不影响客户端的情况下交换实现。
答案 1 :(得分：4)
我建议查看SansORM（NoORM对象映射器）。它专为SQL优先开发而设计，非常适合改进现有模式。
答案 2 :(得分：1)
正如其他人所指出的，如果您的数据库离对象模型不远，ORM只是一个不错的选择。
如果是这种情况，那么两个版本的选项将是通过JPA的Hibernate：
Netbeans有一个从现有数据库生成JPA实体的工具。此实体不依赖于Netbeans，因此您可以在初始逆向工程后使用其他IDE。
Spring Data JPA可以避免编写琐碎的查询，并专注于硬查询。
答案 3 :(得分：0)
如果您可以在对象下建模数据库，Hibernate运行良好 反之亦然，您可能会将数据库模型作为您的域模型。您需要评估这两个模型的距离，否则您将要映射数据库=＆gt; ORM对象=＆gt;你的域名模型。我会避免这种情况。
如果我想跳过ORM部分，我发现自己对JDBI感到非常满意，我更喜欢Spring JDBC Template