我现在在使用O / R映射器或只是坚持传统数据访问之间真的很疯狂。出于某种原因，每次我提出O / R地图制作者时，其他开发人员都会畏缩并谈论性能问题或一般情况下它们是如何糟糕的。我在这里错过了什么？我正在研究LINQ to SQL和Microsoft Entity Framework。这些索赔中有任何依据吗？如果我想使用O / R映射器，我必须妥协什么样的事情。感谢。
答案 0 :(得分：10)
这一开始似乎是一个无关的答案，但是：我的一方利益是二战时期的战斗机。所有战斗国家（美国，英国，德国，苏联，日本等）在战争期间都建立了一批不同的战士。其中一些使用径向发动机（P47，Corsair，FW-190，Zero）;一些使用内联液冷发动机（Bf-109，Mustang，Yak-7，Spitfire）;有些使用了两个引擎而不是一个（P38，Do-335）。有些使用机枪，有些使用大炮，有些则使用两种。如果你能想象，有些甚至是用胶合板制成的。
最后，他们都真的非常快，并且在一位有能力，经验丰富的飞行员的手中，他们会在心跳中射击你的新秀屁股。我不认为很多飞行员都在想着“哦，那个白痴正在用径向发动机飞行 - 我根本不用担心他”。每个人都明白，实现最终目标有很多不同的方法，每种方法都有其特殊的优点和缺点，具体取决于具体情况。
ORM与传统数据访问之间的争论就是这样，任何程序员都应该胜任这两种方法，并选择适合手头工作的选项。
答案 1 :(得分：5)
我很长时间都在为这个决定而努力。我认为我有两个主要原因犹豫不决。首先，O / R地图制作者表示对应用程序的关键部分发生的事情缺乏控制，其次，因为很多次我对90％的情况下令人敬畏的解决方案感到失望但是最后的情况很糟糕10％。当然，一切都适用于来自作者的select *，但是当你提高复杂性并拥有一个高容量的关键系统并且你的职业生涯就在线上时，你觉得你需要完全控制来调整每个查询模式和字节通过电线。包括我在内的大多数开发人员在工具第一次使我们失败时感到沮丧，我们无法做我们需要做的事情，或者我们的需求偏离了工具支持的既定模式。我可能会因为提到工具中的特定缺陷而受到抨击，所以我会留下它。
幸运的是，Anderson Imes最终说服我使用CodeSmith尝试netTiers template。 （不，我不为他们工作。）经过一年多的使用，我不敢相信我们没有早点做到。我的团队使用Visual Studio DB Pro，在每次签入时，我们的持续集成构建都会删除一组新的数据访问层程序集。这会自动处理所有常见的低风险内容，但我们仍然可以为棘手的位编写自定义的sprocs并将它们作为生成的类的方法包含在内，我们也可以为生成的代码自定义模板。我强烈推荐这种方法。可能还有其他工具允许这种级别的控制，并且有一个更新的CodeSmith模板，称为PLINQO，它使用LINQ to SQL。我们尚未对此进行检查（不需要），但这种整体方法有很多优点。
杰里
答案 2 :(得分：2)
O / RM工具旨在在大多数情况下表现良好。它将为您缓存实体，它将以批量执行查询，它具有非常低级别的优化对象访问权限，这比手动为属性分配值更快，它们为您提供了一种非常简单的方法来合并使用面向方面编程的变体现代技术如拦截器，它将为您管理实体状态，帮助解决冲突等等。
现在，这种方法的缺点通常在于缺乏对事物如何在极低水平上运作的理解。最经典的问题是“SELECT N + 1”（link）。
我已经和NHibernate合作了2.5年了，而且我几乎每天都在发现一些关于它的新东西...
答案 3 :(得分：2)
好。在大多数情况下。
使用ORM的生产力优势在大多数情况下都会超过失去对数据访问方式的控制。
没有那么多人会避免C＃，为了编程是MSIL或汇编，虽然这会给他们更多的控制权。
答案 4 :(得分：1)
我看到很多OR映射器的问题是你得到了膨胀的域对象，这些对象通常与你的数据访问框架的其余部分高度耦合。我们的开发人员也对此感到畏惧:)将这些对象移植到另一种数据访问技术上更加困难。如果您使用L2S，则可以查看生成的代码。它看起来像一团糟。 NHibernate可能是最好的之一。如果您正确设计，您的实体完全不了解您的数据访问层。
答案 5 :(得分：1)
这实际上取决于具体情况。
我从一家使用调整过的ORM的公司转到一家没有使用ORM并且一直编写SQL查询的公司。当我询问使用ORM来简化代码时，我看到了面孔的空白，然后是它的所有底片：
on on
好吧，在那里工作几周后，我注意到了：
在我指出大部分内容之后，他们写了一个“DBO”，因为他们不想把它称为ORM。他们决定从头开始编写一个而不是调整一个。
此外，很多争论来自于我对ORM的无知。我见过的每个ORM都允许自定义查询，甚至遵循ORM的约定，您可以编写非常复杂和详细的查询，通常更易于阅读。此外，他们往往非常干，你给他们你的架构，他们把剩下的都计算出来，直到关系映射。
现代ORM有很多工具可以帮助您，例如迁移脚本，访问相同对象的多个数据库类型，因此您可以利用NOSQL和SQL DB的优势。但是如果要使用它，你必须为你的项目挑选合适的ORM。
答案 6 :(得分：0)
我首先从阅读Rockford Lhotka的书C＃业务对象开始进入ORM映射和数据访问层。他花了数年时间研究DAL的框架。虽然他开箱即用的框架非常臃肿，但在某些情况下，他有一些很好的想法。我强烈推荐这本书给任何看过ORM mappers的人。我受他的书的影响足以带走他的很多想法并将它们构建到我自己的框架和代码生成中。
答案 7 :(得分：0)
没有简单的答案，因为每个ORM提供商都有自己特定的优点和缺点。一些ORM解决方案比其他解决方案更灵活。在使用之前，开发人员有责任了解这些。
但是，使用LinqToSql - 如果您确定不需要切换SQL Server，那么这就解决了ORM映射器中出现的许多常见问题。它允许您轻松添加存储过程（作为静态方法），因此您不仅限于生成SQL。它使用延迟执行，以便您可以有效地将查询链接在一起。它使用部分类来允许您轻松地将自定义逻辑添加到生成的类中，而无需担心重新生成它们时会发生什么。也没有什么可以阻止你使用LINQ创建自己的，抽象的DAL - 它只是加快了这个过程。但主要的是，它减轻了创建基本CRUD层所需的乏味和时间。
但也有缺点。您的表和类之间将存在紧密耦合，性能略有下降，您可能偶尔会生成效率低于预期的查询。而且你被捆绑在SQL Server中（尽管其他一些ORM技术是与数据库无关的）。
正如我所说，主要的是在将颜色固定到特定方法之前要先了解利弊。