具有大型项目的实体框架

Question

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

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

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

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

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

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

您认为它值得信赖吗？

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

Answer 1

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

我想，你会很快熟悉EF的用法，因此我不认为不熟悉会长期存在问题。

Answer 2

我决定不使用EF。 我不会冒这个大项目使用它的风险。

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

谢谢大家的评论..

*在我再次直接进行ADO之前，我将尝试一下FluentData和Dapper .. 我将打开一个新问题，如果你们想对这两个轻型ORM发表评论，我会稍后发布这个链接。

Answer 3

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

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

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