从旧的 DataLayer 到 LINQ 再到 SQL / Entity Framework答案

【问题标题】：From old DataLayer to LINQ to SQL / Entity Framework从旧的 DataLayer 到 LINQ 再到 SQL / Entity Framework
【发布时间】：2009-10-06 10:23:15
【问题描述】：

在 SO 和 Google 上有一些“我应该选择这个还是那个”的问题，还有很多比较 LINQ2SQL 和 LINQ2E 的问题。我已经看到了缺点、差异、缺点、优点、限制等。

我不能说我是专家，但我想知道如果你遇到这种情况“你会怎么做”以及为什么。

我必须向最近迁移到 3.5 的“旧”2.0 应用程序添加一些东西（它是开箱即用的编译，到处都有一些警告）。因为我必须添加新的东西，所以我想开始使用 LINQ（2SQL 或实体）。

我过去曾使用过 Linq2SQL，我喜欢它是一种快速、易于使用的解决方案……如果您不想做任何太奇怪的事情。如果您来自旧的“记录集”，那么表等之间的自然 1..1 关系是天赐之物。同样不错的是能够根据您要使用的表集来拥有不同的数据上下文。

随着事物的数量和新功能的增长，我开始考虑尝试使用实体框架而不是 Linq2SQL 的可能性。我不喜欢后者的是，如果不诉诸 hack，就无法处理 Many2Many 关系。

这就是实体框架的用武之地。但是，你不能像使用 Linq2Sql 和“datacontexts”那样拥有多个“小模型”，除非你牺牲 some 的东西和一些other 东西。

该数据库目前有 218 个表，并且没有显着增长。时不时地有一张新桌子，但我们不是在谈论每天 10 张桌子。我想说，在接下来的一年的开发中，我们将“艰难地”达到 250 张桌子。

有Many 2 Many关系，有些仅与PK/PK有关，有些与聚合（Entity Framework没有magically handle，但它可以处理它们。这就是原因为什么我不想从 Linq2SQL 开始，除非 hack 是“好的”并且是可接受的方法。

你会怎么做？妥协 N..N 关系（知道即使有黑客攻击，它也不会像集成解决方案那样优雅或“受支持”）并使用 Linq2SQL 及其“拥有许多您创建和销毁的小型数据上下文”的理念或，另一方面，继续使用实体框架，拥有一个包含所有表或关系的巨大数据模型，然后从那里开始？即使创建多个模型也有缺点（请参阅那里的链接）并且拥有一个巨大的模型也有缺点。

还有关于微软“放弃”Linq2SQL 的非官方 cmets（我怀疑，但你永远不知道）。我们的数据库是 MSSQL，我认为这种情况不会很快改变。

我们将不胜感激。

【问题讨论】：

您对使用 LinqToSql/EntityFramework 附带的 O/R 设计器的概念有多满意？您似乎坚持要获得这种支持，但您有 200 多张桌子。在这种规模下，像 SQLMetal/EdmGen 这样的东西可能会提供更好的整体体验。
Converting a LinqToSql DAL to EntityFramework的可能重复

标签： .net linq-to-sql entity-framework orm linq-to-entities

【解决方案1】：

我在 Linq2SQL 中处理多对多关系就好了。

请参阅here，了解一种可以解决您痛苦的neato 扩展方法！

就我个人而言，我发现使用一个整体模型是最容易处理的。

【讨论】：

虽然我喜欢这个解决方案（就像我链接的那个一样），但它仍然有些复杂，需要 dbml 手动编辑（添加属性）并且还破坏了设计器。 “一个整体模型”是指实体模型还是一个单一的 Linq2sql 数据上下文？
我没用过EF，所以说的是Linq2SQL。很少有用于 Linq2SQL 的自定义生成工具，这使得修改变得更加容易。在我简单地将所有表格拖到设计器界面后，我目前使用了经过大量修改的 codeplex.com/l2st4 版本来修复所有内容。
我有一个模型，在单个 Linq-to-SQL 模型中包含 400 多个实体。工作得很好。如果您在 .net 3.5 下执行此操作，请使用 L2S。当 4.0 发布并稳定时，可能值得重新评估 EF，但 EFv1 对于比 NorthwindEF db 更复杂的任何东西都有太多的展示... JMHO
@KristoferA：使用具有 400 多个实体的模型似乎与此相反：geekswithblogs.net/michelotti/archive/2007/12/27/118022.aspx您是在使用 n 层 DAL，还是只传递一个数据上下文？

【解决方案2】：

在你的情况下我会怎么做？我会使用 NHibernate，可能还会使用 Castle Active Record。

为什么？因为该解决方案为“现实世界”场景提供了最佳支持，尤其是您提到的场景。 NHibernate 与您的项目一起扩展并且不会限制您。它基本上是免费的。 NHibernate 是一个非常成熟、经过充分测试的解决方案。

你没有提到 NHibernate 作为你正在研究的东西，所以我不确定在这方面什么不吸引你（看起来你已经阅读了足够多的内容，你会遇到这个选项） .

LinqToSql/EntityFramework 没有提供很多您无法通过 NHibernate 获得的功能。

【讨论】：

我没有考虑 NHibernate 的原因是因为我们已经使用了一个已经被作者抛弃的 OLD ORM (Gentle)。我们不想跳入未来可能会消失的另一个项目（无论它多么成熟），再加上（据我所见/阅读/听到的）一开始就难以掌握的事实。此外，Linq 提供了很好的语法。 ;) 当我们选择 Gentle 而不是 NHibernate 时，那是因为 Gentle “更好、更快且未删减”。我猜这是 2005 年的错误决定。:S
也就是说，我不放弃NHibernate，因为它现在看起来已经很成熟了，但我担心它会带来一个阶梯式的学习曲线......
NHibernate 支持 Linq。在我看来，NHibernate 与其他 ORM 具有相似的学习曲线。一些 ORM 看起来比实际简单。 :) 大多数“简单”的 ORM 都是这样，因为它们缺乏功能和处理许多现实世界场景的能力。如果您必须选择一种 Microsoft ORM 解决方案并且您对未来感到担忧，那么 EntityFramework 的未来会更加光明。