.net 开发人员必须关心将来更改ORM的可能性吗？

让我们想象一下，我开始开发一个项目。所以，我必须认真考虑将来改变ORM的可能性吗

或者更准确地说：

是否要将当前项目中使用的ORM更改为其他ORM。如果是，原因是什么

你真的这样做过吗？如果是，原因是什么

---

实际上，我在想，投入大量精力开发ORM不可知解决方案是否有价值。

在项目过程中更改ORM的几率非常低。有一个非常好的机会，你所做的任何努力，以确保你可以切换你的ORM将最终白费。你必须权衡一下改变ORM的微小可能性和改变ORM的额外努力

回答您的问题：

没有

通常，如果您使用的工具无法满足某些实质性需求，您会更改ORM。我真的想不出任何这样的例子有什么意义——通常你可以绕过这样的问题

---

在一天结束时，我会简单地确保我选择了一个适合我的ORM（像NHibernate这样的东西不会真的出问题），并确保您的代码是松散耦合的，这将确保您的数据访问代码是隔离的。这不仅从可维护性的角度来看是好的，而且从可测试性的角度来看也是好的。

是的，我认为您应该关心它，在多大程度上是完全主观的问题。应该考虑应用程序的所有层，尤其是如果您认为您的代码将在很长的时间内就位，或者如果您认为您的应用程序将有显著的增长

关于您的具体问题：

我有几个项目使用各种不同的存储系统和框架来管理数据，如果它们之间有一个一致的战略就好了，但我们会努力完成我们有时间完成的事情。我对与我一起工作的团队的一般指导是，仅在对项目有意义的情况下选择ORM，并将抽象放在适当的位置以便于使用。一般来说，我更喜欢NHibernate（我有更多的经验），但有很多好的解决方案

是的，我至少参与过两个项目，其中我们的唯一目的是删除现有的第三方组件（包括ORM框架）并用其他组件替换它们。在一个案例中，我们从一个自制的ORM转移到NHibernate，在另一个案例中，我们从一个第三方ORM转移到一个客户要求我们为他们设计的ORM。这两个项目都很复杂，涉及大量应用程序无法正常处理的更改。其中一部分（并非全部）可归因于代码与其数据存储策略紧密结合的事实

---

对我来说“有价值”=如果迁移到另一个ORM的概率为10%，从头开始迁移的成本（即如果项目开发时根本不考虑迁移的可能性）为C，那么将高达C*10%的精力用于透明迁移支持是合理的。ORM代表什么？即实体框架、LINQ到SQL，NHibernate等。关于2-那么迁移到另一个ORM不是您描述的重构的主要原因是真的吗，也就是说，有更重要的问题最终导致决定如此显著地重构项目（更改所有组件通常~=几乎完全重写它）？事实上，DAL是一个项目进行重构的重要原因。有问题的客户试图将其应用程序扩展到一个比以前更大的业务中（即，公司而非SMB），客户的要求是制定某些数据库相关政策，DAL无法很好地处理这些政策。特别是允许SP运行而不是直接查询等。这些是（当时）他们选择的ORM的主要限制。谢谢-同意，DAL是非常重要的部分。这取决于你如何定义“项目”以及你的项目进行了多长时间。我认为对于一些项目（那种永远持续下去的项目），这是非常可能的。