我现在在使用O/R映射器或只是坚持传统数据访问之间真的很疯狂.出于某种原因,每次我提出O/R地图制作者时,其他开发人员都会畏缩并谈论性能问题或一般情况下它们是如何糟糕的.我在这里错过了什么？我正在研究LINQ to SQL和Microsoft Entity Framework.这些索赔中有任何依据吗？如果我想使用O/R映射器,我必须妥协什么样的事情.谢谢.
Mus*_*sis 10
这看起来似乎是一个无关的答案,但是:我的一方利益是第二次世界大战时代的战斗机.所有战斗国家(美国,英国,德国,苏联,日本等)在战争期间都建立了一批不同的战士.其中一些使用径向发动机(P47,Corsair,FW-190,Zero); 一些使用内联液冷发动机(Bf-109,Mustang,Yak-7,Spitfire); 有些使用了两个引擎而不是一个(P38,Do-335).有些使用机枪,有些使用大炮,有些则使用两种.如果你能想象,有些甚至是用胶合板制成的.
最后,他们都非常快,并且在一位有能力,经验丰富的飞行员手中,他们会在心跳中射击你的新秀屁股.我不认为很多飞行员都在想着"哦,那个白痴正在用径向发动机飞行 - 我根本不用担心他".每个人都明白,实现最终目标的方法有很多种,每种方法都有其特殊的优点和缺点,具体取决于具体情况.
ORM与传统数据访问之间的争论就是这样,并且任何程序员都应该能够胜任这两种方法,并选择适合手头工作的选项.
我很长时间都在为这个决定而苦苦挣扎.我认为我有两个主要原因犹豫不决.首先,O/R地图制作者表示对应用程序的关键部分发生的事情缺乏控制,其次,因为很多次我对90%的情况下令人敬畏的解决方案感到失望但是最后的情况很糟糕10%.当然,一切都适用于来自作者的select*,但是当你提高复杂性并拥有一个高容量的关键系统并且你的职业生涯就行了时,你觉得你需要完全控制来调整每个查询模式和字节通过电线.包括我在内的大多数开发人员在工具第一次使我们失败时感到沮丧,我们无法做我们需要做的事情,或者我们的需求偏离了工具支持的既定模式.我可能会因为提到工具中的特定缺陷而受到抨击,所以我会留下它.
幸运的是,Anderson Imes最终说服我使用netTiers模板尝试CodeSmith.(不,我不为他们工作.)经过一年多的使用,我不敢相信我们没有早点做到.我的团队使用Visual Studio DB Pro,在每次签入时,我们的持续集成构建都会删除一组新的数据访问层程序集.这会自动处理所有常见的低风险内容,但我们仍然可以为棘手的位编写自定义的sprocs并将它们作为生成的类的方法包含在内,我们也可以为生成的代码自定义模板.我强烈推荐这种方法.可能还有其他工具允许这种级别的控制,并且有一个更新的CodeSmith模板,称为PLINQO,它使用LINQ to SQL.我们还没有检查过(不需要),但这种整体方法有很多优点.
杰瑞
小智 1
我发现很多 OR 映射器的问题是域对象臃肿，这些对象通常与数据访问框架的其余部分高度耦合。我们的开发人员也对此感到畏缩:)将这些对象移植到另一种数据访问技术更加困难。如果你使用L2S，你可以看一下生成的代码。看起来一团糟。NHibernate 可能是这方面最好的之一。如果您设计正确，您的实体完全不知道您的数据访问层。