2

假设 ORM 处于休眠状态。

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

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

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

如果我误解了为什么休眠/ORM 可能会或可能不会有好处，我希望得到评论。

谢谢你。

4

4 回答 4

1

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

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

于 2009-04-27T18:17:08.870 回答
1

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

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

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

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

于 2009-04-27T18:17:46.390 回答
0

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

于 2009-04-27T18:52:18.007 回答
0

我认为根据未知数与已知数做出任何决定通常是一个坏主意。无论您是在决定数据访问/持久性策略、购买什么汽车或上哪所大学，您都应该最重视您今天想要的事情，而不是担心可能发生或可能不会发生的事情明天。

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

所以简而言之，根据它解决问题的能力和满足你今天的需求来选择一个 ORM。

于 2009-04-28T01:53:49.553 回答