有没有人在开发过程中切换过ORM解决方案？

Question

在我目前的工作中，我在EntityFramework和DbContext之上实现了Repository / UoW模式。我找到的唯一有效理由是，如果您不想依赖于某个特定的ORM解决方案。我只想看看是否有人这样做过，在项目的一半（比如说，一年后）决定：“Geez，我很高兴我实现了Repository Pattern，因为我需要从EntityFramework切换到NHibernate。 “除了crud和一些带有连接的基本查询（使用LINQ）之外，我觉得这个额外的抽象层很烦人，因为你必须在数据库中创建表，编写一个存储库，编写一个服务（如果你想要典型的3分层拱门）和必要的前端，如控制器和视图。

更新

想知道是否有人在项目之前切换ORM以及为什么？

Answer 1

您不必这样做。我不知道任何实际转换的项目，转换实际上还包括很多工作 如果您阅读Ayende's blog，您会发现许多针对存储库的要点。

执行此操作的唯一原因是，您正在开发一个可以根据特定用例与多个ORM一起使用的框架。

此外，每个表都有一个存储库非常浪费开发人员的时间 即使您使用存储库，只需要一个具有某些特定于实体的扩展的通用存储库就足够了。

说完这一切之后，我仍然使用存储库，主要是因为我不喜欢在不相关的代码中直接引用第三方库。但这是一个偏好问题，而不是我能证明的最佳实践。

Answer 2

有很多微博建议使用存储库模式。

这个谷歌搜索“实体框架工作单元”支持这一点。

entity framework unit of work

我认为在您的代码中更重要的是确保它的可维护性和灵活性是遵循SOLID原则。最具体的是界面隔离模式。如果您正在编写接口，那么当您编写接口时，数据存储库实现就变得无关紧要了。

我有时使用Azure Blob存储来存储数据，所以我有两个我的界面实现：

IDtoEntityRepository

我从两个不同的数据存储中提取相同的数据类型，并且每个数据存储对处理数据有不同的要求。 所以我最终得到了1个sql实现和1个azure blob存储实现。 sql实现碰巧用实体框架编码，但我可以轻松地用Telerik的Orm编写一个新的类代码：

TelerikOrmDtoEntityRepository

任何针对IDtoEntityRepository编码的类都不关心实现。通过这样做，我将任何数据层实现细节与调用代码分离。

Answer 3

只需创建所需的最小对象即可提供快速测试且可靠的功能代码。此后，您可能会关心重构等等，然后有一天，当您决定更改ORM工具时，您将使用诸如存储库和工作单元设计模式之类的机制进行操作。

除此之外，如果您已经熟悉了存储库模式，那么预测它的实用性可能是一个好主意，因为这可能使您不仅可以更改ORM工具，而且可以在某些情况下直接使用ADO.NET

我认为依赖第三方工具（例如ORM等）并不坏，然后我认为你想为最好的评级工作，例如NHibernate，我比其他任何人更喜欢存在的ORM工具。这是个人意见。

我所说的背后的想法是不要写一堆类，以防你有一天可能需要它们。在你真正需要它们时写下它们。