6

我刚刚完成了此处找到的 MvcMusicStore 教程。这是一个带有工作源代码的优秀教程。到目前为止我最喜欢的 MVC v2 教程之一。

该教程是我对使用 ADO.NET Entity Framework 的第一次介绍，我必须承认其中大部分内容非常快速和直接。但是，我担心可维护性。当客户向他们的站点请求需要新字段、表格和关系的附加功能时，该框架的可定制性如何？

我非常担心无法有效地执行客户的变更单，因为实体模型基本上是拖放式的计算机生成代码。我在代码生成器方面的经验并不好。如果模型的内部出现问题，我无法将矮胖子重新组合起来怎么办？

从长远来看，我想知道使用人类可以阅读和编辑的手写模型是否比使用实体框架更有效。

是否有人对实体框架进行了足够的工作以说他们很乐意在非常流畅的开发环境中使用它？

4

4 回答 4

7

在我目前的项目中，我已经使用实体框架（V1.0）大约一年了。我们有 100 个表，都添加到 edmx。我们面临的问题（虽然不确定新的实体框架是否解决了这些问题）

  1. 当您习惯于 VS.net IDE 时，您将习惯于从您的 IDE 中执行所有拖放操作。问题是，一旦您的 edmx 托管了 100 多个表，IDE 就会真正停止运行，您必须等待 3-4 分钟才能响应

  2. 有这么多表格，您在 edmx 上进行的任何编辑都需要很长时间。

  3. 当您要使用版本控制时，比较 10000 行 XML 是相当痛苦的。考虑合并 2 个分支，每个分支都有 10000 行 edmx、表、表之间的新关联、已删除的关联以及来回比较 xml。如果您认真考虑合并 2 个大 edmx 文件，您将需要一个好的 xml 比较工具

  4. 出于性能原因，我们不得不将 csdl、msl 和 ssdl 作为嵌入式资源

  5. 您的 edmx 必须始终与您的数据库同步，或者至少，当您尝试更新 edmx 时，它会尝试同步，如果它们不同步，可能会抛出一些模糊的错误。

  6. 请注意，您的实体（表/视图）应该始终有一个主键，否则您将得到模糊的错误。在这里查看我的另一个问题

我们在使用 EF 时所做的事情/我将来可能会考虑的事情

  1. 通过对逻辑分组/链接在一起的表使用 1 个 edmx 来使用多个 edmx。请注意，如果您这样做，每个 edmx 都应该存在于自己的命名空间中。如果您尝试将 2 个相关表（例如人员和地址）添加到同一命名空间中的 2 个 edmx，您将收到一个编译器错误，指出外键关系已定义。（提示：创建一个文件夹并在该文件夹下创建edmx。如果您尝试在没有文件夹的情况下更改edmx中的命名空间，则下次打开/编辑它时它不会正确保存命名空间）

    fewer tables in edmx => less heavy
container => good

    edmx 中的表更少=> 合并 2 个分支时更容易合并

  2. 请注意对象上下文不是线程安全的事实

  3. 您的存储库（或您使用的任何 DAO）应该负责创建和处置它创建的容器。使用 DI 框架，尤其是在 Web 应用程序中，对我们来说很复杂。Web 请求是从线程池提供的，并且在提供 Web 请求后，容器没有被正确处理，因为线程本身没有被处理。容器被重用（当线程被重用时）并产生了很多并发问题

  4. 不要相信你的 VS IDE。获得一个好的 XML 编辑器并知道如何编辑 edmx 文件（尽管您不需要编辑设计器）。弄脏你的手

  5. 当你执行查询时，总是总是总是（只是不能强调这一点）运行 SQL 分析器（我的意思是代码的每一步）。尽管查询看起来很复杂，但您会惊讶地发现您点击数据库示例的次数：（抱歉，无法将代码转换为正确的格式，有人可以格式化吗？）

    var myOrders = from t in context.Table where t.CustomerID=123

    选择 t; //上面的查询还没有执行

    if(myOrders.Count>0)//DB query to find count { var firstOrder = myOrders.First()//DB query to get first result }

    更好的方法

    // 查询物化，只有 1 次命中 DB，因为我们使用 ToList() var myOrders = (from t in Context.tables where t.customerID=123 select t).ToList();

    if(myOrders.Count>0)//no DB hit
{
//do something
var myOrder = myOrders[0];//no DB hit
}

  6. 知道何时使用跟踪和不跟踪（只读），并且网络应用程序的读取次数多于写入次数。初始化容器时正确设置它们

  7. 我忘记编译查询了吗？看 这里更多好东西

  8. 从数据库中取回 1000 行时，请确保使用 IQueryable 并分离 objectContext，以免内存不足

更新：

Julie Lerman用类似的解决方案解决了同样的问题。她的帖子还指出了Ward在处理大量表格方面的工作

于 2010-06-24T18:59:53.367 回答
1

我对实体框架不太熟悉，但我相信它只是生成一个可以手动编辑的 EDM 文件。我知道我经常使用设计器生成的 Linq-to-SQL DBML 文件来完成此操作（手动编辑它们通常比使用设计器进行小调整要快）。

于 2010-06-24T17:54:32.837 回答
1

您知道，如果任何开发人员可以对此提供一些见解，我会很感兴趣。任何实体框架示例似乎只包含大约十到二十个表，这确实是小规模的。

在具有数百甚至一千个表的数据库上使用 EF 怎么样？

就我个人而言，我认识几个被 LINQ-to-SQL 烧毁的开发人员和组织，他们推迟了一年左右的时间来看看 EF 的发展方向。

于 2010-06-24T18:06:36.497 回答
1

从 Entity Framework 4（使用 Visual Studio 2010）开始，生成的代码从 T4（文本模板转换工具包）文件中输出，您可以对其进行编辑，这样您就可以完全控制生成的内容。请参阅Oleg Sych 的博客，该博客是关于 T4 的信息库。代码生成不是问题，T4 开启了如此多的视角，我再也离不开它了。

我目前正在从事一个项目，我们使用 Entity Framework 4 作为数据访问层，并使用 Scrum 作为敏捷项目管理方法。从一个 sprint 到另一个 sprint，添加了几张表格，修改了其他表格，添加了新要求。当您遇到每个潜在的 EF 问题时（例如知道默认情况下数据库中的默认值不会保留在 .edmx 文件中，或者将可为空的列更改为不可为空的列并且更新设计器不会更改映射的属性状态），你很高兴去。

编辑：回答您的问题，它是 EF 4，其代码生成基于 T4 而不是 T4 支持 EF。在 EF 3.5（或 EF 1.0，如果您愿意）上，理论上您可以通过从头开始编写 T4、解析 T4 代码中的 EDMX 文件并生成实体来使用 T4。考虑到所有这些都已由 EF 4 完成，这将是相当多的工作。此外，Entity Framework 3.5 仅支持一种类型的实体，而 EF 4 作为 POCO 实体的内置或可下载模板（什么都不知道）关于持久性），自我跟踪实体......

考虑到 Entity Framework 本身，我认为它在其第一个版本中缺少许多功能，虽然可用，但使用起来非常令人沮丧。EF4 得到了更大的改进。它仍然缺少一些基本功能（如枚举支持），但它现在已成为我选择的数据访问层。

于 2010-06-24T18:44:24.160 回答