ORM 是否与现有应用程序集成或我不理解？

Question

假设 ORM 处于休眠状态。

我不知道怎么问这个。我想构建一个可以替换另一个应用程序的一部分。例如，假设我有一个包含各种模块的应用程序，称为“大”应用程序。这个应用程序可以处理人力资源、财务、采购、技能组合等。但也许，出于某种原因，我不喜欢技能组合模块，但我喜欢应用程序的其余部分。我想构建一个应用程序，它使用与“大”应用程序的其余部分相同的数据库，但使用我的软件作为该部分的前端。

我可以构建我的应用程序并让它直接访问数据库而无需 ORM。我的问题是在这里使用 ORM 是否有优势。我认为这是因为如果“大”应用程序消失并且购买了另一个应用程序，我们可以继续使用我的技能集版本，因为我使用的是休眠而不是直接打东西。我仍在学习，但我认为我的应用程序使用了我命名的对象，并且在我刚才描述的情况下，我只需要更改我的映射文件或/和我的代码。

这是另一个例子。我有一个遗留应用程序和遗留数据库。它使用数据库 X。我决定不再喜欢用于获取数据的旧终端仿真器应用程序，并且我想要一个图形版本。我可以在我的应用程序中使用 hibernate，当我最终决定摆脱旧数据库并更改为最新的 Oracle 或 SQL Server 时，我可以轻松地做到这一点吗？还是我的数据库会发生如此大的变化以至于无论如何都无关紧要（我建议在更改为新数据库时需要捕获更多信息）？

如果我误解了为什么 hibernate/ORM 可能会或可能不会有好处，我希望有 cmets。

谢谢。

Answer 1

如果数据库架构更改为完全不同的东西，我认为您不会从休眠中获得巨大的好处，您可能需要更改的不仅仅是映射 - 特别是如果将更多“结构”添加到数据库（表，列和此类架构的东西）。也就是说，如果数据库的结构基本相同，但可以说只是列名和表名发生变化，并且合并了几个表或类似的东西 - 您只需更改映射即可。

但我真的建议使用 hbernate 来实现数据库不可知性，这是一条非常简单的方法。

然后仅仅因为如果你的整个数据库被改变它并不能完全帮助你，它的其他力量如此之多，我会选择它而不是直接数据库访问。

最后，您可以考虑使用服务层，例如抽象出数据访问的存储库模式，这样如果数据库发生变化，您的应用程序业务就不需要更改。

Answer 2

从一个 DBMS 切换到另一个（从 Oracle 到 SQL Server）是一件事，使用 ORM 肯定会更容易。

至于从一个“大应用程序”切换到另一个“大应用程序”，我怀疑使用 ORM 是否会有这么大的帮助。很可能数据库结构和业务逻辑会完全不同，以至于您会发现自己要重写大量代码。

Answer 3

您可以使用 Hibernate Tools 生成域对象，如果这样做的话，它将变得轻松而快速。但是，如果你手写所有的对象，你会死的。我认为重写部分应用程序并更好地了解hibernate是个好主意。

Answer 4

我认为根据 未知与已知。无论您是在决定数据 访问/持久性策略，买什么车，或者去什么大学 到，你应该把最大的重量放在你知道你想要的东西上 今天，而不是担心明天可能发生或可能不会发生的事情。

所以在考虑 ORM 时，我不会太担心诸如应用之类的事情 “离开”或 DBMS 发生变化（除非已经讨论过，或者 贵公司有这方面的历史）。我并不是说这些不是永远不会发生的事情，而是说它们应该退居二线，考虑到通常更重要的可维护性、性能和开发人员生产力的考虑因素。

因此，简而言之，根据其解决问题和满足您当前需求的能力来选择 ORM。