6

我和我的团队将开始一个新项目，我们正处于探索和测试一些新的（或不太新的）技术的阶段。

直到今天，我们还在使用带有 DBDataReaders 的经典 ADO、用于延迟加载的代理，在某些情况下还使用 DataTables。

该团队由 3 名开发人员和 1 名数据库设计师组成。我们的项目每个项目至少包含 130 张桌子。

我们的新项目有增长的潜力，所以我们肯定会有 100 张桌子。

在过去的两天里，我一直在阅读并使用 EF5 进行一些简单的测试，但我仍然无法决定是否应该使用它。

  1. 我们通常将一个大项目拆分为许多“模块”项目，使我们能够在源代码控制下更快更好地工作。我们要为整个数据库使用一个大的“edmx”吗？
  2. 由于我们有一个数据库设计器，我怀疑 CodeFirst 不是一个选项。那么是否值得将 EF 与 Database First 方法一起使用？
  3. 如果我们使用数据库优先方法，EF 是否足够聪明，可以正确检测所有关系并准备好使用，而无需我进行更多额外配置？（通过额外的配置，我的意思是我必须编写 DataAnnotations 或必须覆盖 DbContext）
  4. 就个人而言，我发现自己对使用 sql 设计数据库非常有信心。我唯一的烦恼是当我的类列表中的实体发生更改时，我必须更新所有的选择、删除、更新、插入脚本。EF 会为我解决这个问题，但除此之外，我开始相信它会降低性能并最终降低我的生产速度，因为我们不熟悉它。

你认为它值得吗？

*除了 DataAnnotations 和 DbContext ovveride，是否有人使用纯 T4 模板来创建表（模式）？

4

3 回答 3

4
  1. 我绝对建议创建多个模型。您可以选择要为每个表映射的表、视图和存储过程。
  2. 数据库优先绝对没问题。
  3. 如果已设置数据库约束，则 EF 将识别它们。你不会绕过小的修改，但总而言之，EF 做得很好。
  4. 使用 EF 会对查询性能产生轻微影响。但在大多数情况下，这不会成为问题。在少数情况下，您可能会遇到不可接受的性能损失，您可以在必要时通过将自己的 SQL 注入 EF 来进行优化。

我认为，您很快就会熟悉 EF 的用法，因此我认为不熟悉不会长期成为问题。

于 2013-05-22T19:12:13.727 回答
3

我决定不使用EF。我不会冒险在大型项目中使用它。

使用它所需的所有工作，处理错误的可能性，额外的开销。我更喜欢编写更多的 sql 代码并花更多的时间维护，而不是处理生成的模型或检查生成的查询的 sql 分析器。

谢谢大家的意见..

*在我再次直接使用 ADO 之前，我将对 FluentData 和 Dapper 进行一次尝试。我会提出一个新问题，所以如果你们想对这两个轻量级 ORM 发表评论，我稍后会发布链接。

于 2013-05-22T21:58:00.467 回答
-1

如果您的数据库结构成熟，EF 应该是一个不错的解决方案。

如果数据库结构正在开发中，或者随着时间的推移会发生很大变化，我会断言 EF 可能不是最适合您的。

当发生结构更改（以及数据库层的潜在接口更改）时，需要刷新 EF。您应该考虑如何在已开发的代码库中管理数据库更改。

于 2013-05-22T18:12:32.403 回答