为ORM假设Hibernate。
我不知道怎么问这个。我想构建一个可以替换另一个应用程序的应用程序。例如，假设我有一个带有各种模块的应用程序，称为“大”应用程序。这个应用程序可以处理人力资源，财务，购买，技能组等。但是，无论出于何种原因，我可能不喜欢技能集模块，但我喜欢应用程序的其余部分。我想构建一个应用程序，该应用程序使用与“大”应用程序的其余部分相同的数据库，但使用我的软件作为该部分的前端。
我可以构建我的应用程序并让它直接命中数据库而不使用ORM。我的问题是在这里使用ORM是否有优势。我想是因为如果“大”应用程序消失并且购买了另一个应用程序，我们可以继续使用我的技能版本，因为我正在使用休眠而不是直接打击事物。我还在学习，但我认为我的应用程序使用了我命名的对象，在我刚才描述的情况下，我只需更改我的映射文件或/和我的代码很少。
这是另一个例子。我有一个遗留应用程序和遗留数据库。它使用数据库X.我认为我不再喜欢用于获取数据的旧终端仿真器应用程序以及我想要的图形版本。我可以在我的应用程序中使用hibernate，当我最终决定摆脱遗留数据库并更改为最新的Oracle或SQL Server时，我可以轻松地解决这个问题吗？或者我的数据库会发生如此大的变化，以至于无论如何都不会有任何问题（我建议在更换到新数据库时需要捕获更多信息）？
我希望发表评论，如果我误解了为什么hibernate / ORM可能会或可能不会带来好处。
谢谢。
答案 0 :(得分：1)
从一个DBMS切换到另一个（从Oracle到SQL Server），使用ORM肯定会更容易。
至于从一个“大应用”转换到另一个“大应用”，我怀疑使用ORM会有多大帮助。数据库结构和业务逻辑很可能与您发现自己重写大量代码的情况不同。
答案 1 :(得分：1)
如果数据库架构变为完全不同的东西，我认为你不会有很大的好处，你可能不得不改变你的映射 - 特别是如果在数据库中添加了更多的“结构”（表，列和这样的架构事物）。也就是说，如果数据库的结构大部分都是相同的，但是让我们说只是列名和表名更改，并且合并了几个表或类似的东西 - 只需更改映射就可以了。
但我真的建议使用hbernate来实现数据库无关性，这是一条非常简单的路径。
然后只是因为如果你的整个数据库发生了变化，它并没有完全帮助你，它会产生如此巨大的其他力量，我会选择这种力量而不是大多数时间直接访问数据库。
最后，您可以考虑使用服务层（如存储库模式）来抽象数据访问，因此，如果数据库发生更改，您的应用程序业务就不需要更改。
答案 2 :(得分：0)
您可以使用Hibernate Tools生成域对象，如果您这样做，那么它将是无痛且快速的。但是如果你手工编写所有物体，你就会死亡。我认为重写部分应用程序并更好地了解hibernate是个好主意。
答案 3 :(得分：0)
我认为根据这个做出任何决定通常都是一个坏主意 未知与知识。您是否决定数据 访问/持久性策略，购买什么车，或去哪所大学 你应该把最重要的东西放在你想要的东西上 今天，而不是担心明天会发生什么或不发生什么。
因此，在考虑ORM时，我不会过多担心应用程序等问题 “走开”或DBMS改变（除非已经谈过，或者 你的公司有这个历史）。我并不是说这些不是永远不会发生的事情，而是说它们应该退回到可维护性，性能和开发人员生产力这些通常更为重要的考虑因素。
简而言之，根据其解决问题和满足您现有要求的能力选择ORM。