多 ORM 解决方案 [关闭]

Question

我想知道开发多 ORM 解决方案的最佳方法是什么。

到目前为止，我看到的所有项目都与 ORM 的选择密切相关，并且他们坚持到最后。 Nhibernate、Castle ActiveRecord、Linq to SQL、WilsomORM、LLBLGen、SubSonic、Entity Framweork，其他...

我在考虑是否应该将这个选择的强关系与项目的其他部分分开。在某种程度上，我可以随时更改 ORM。

目前我唯一的想法是“工厂”检索我的 ORM 对象，然后我会将其映射到某个“内部”对象。

在某些情况下，项目开始时有一些限制，并且在那个时候做出的决定，除了选择一个特定的 ORM 或不同领域的其他东西之外，别无选择。

但是随着时间的推移，几个月，一年左右，许多事情发生了变化，更多的资金，更多的支持，技术的进步，新的框架/想法等等......为我们提供了更好的选择，在这种情况下，它会能够在不对应用程序进行重大更改的情况下更改 ORM 真是太酷了（此时可能是巨大的变化）。

我想知道你的意见。

谢谢你们。

Answer 1

更改您的 ORM 始终是一个耗时的过程，因为 ORM 提供的抽象总是会渗透到您自己的代码中，即使您没有意识到：ORM 的功能（或缺少某些功能！）将在您的代码中可见。选择基于 linq 的 ORM 将更容易切换，因为查询可能更容易转移到另一个 ORM（如果该 ORM 也支持 linq）。但这将是很多工作，因此预先选择功能丰富的 ORM 是明智的。

另一个问题是映射定义，即模型本身：如果没有适当的工具，即使不是不可能，也很困难。如果你看看像 LLBLGen Pro v3 (http://www.llblgen.com) 这样的设计器，你可以使用相同的项目、相同的实体模型和具有不同 ORM 的映射，并且切换很容易（当然你仍然需要更新自己的代码）。

（免责声明：我是 LLBLGen Pro 的首席开发人员。

Answer 2

恕我直言，这始终是一个核心解决方案。将 ORM 类与一些内部类映射总是会导致“双重工作”和问题。某些 DB 模式更改将需要在此映射类中再次更改，出于某种原因，这将需要特别注意不要忘记。

还有其他一些事情要记住：事务、延迟加载、出于某种原因，某些 ORM 的行为与其他 ORM 不同，或者具有或不具有该功能。假设所有都是相似的是不正确的。考虑到这一点，我认为这并不是那么简单。

Answer 3

更改 ORm 可能会导致更改数据访问层。 每个 ORM 都有自己的代码生成模式。 我同意弗兰斯·布马的观点。 （（（选择基于 linq 的 ORM 将更容易切换，因为查询可能可以转移到另一个 ORM（如果该 ORM 也支持 linq）更容易）） 你可以开发你自己的 ORM 并让它生成 LINQ 查询！能够 ？！ 祝你好运