大型项目的实体框架

Question

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

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

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

我们的新项目有增长的潜力，所以我们肯定会有100个表。

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

1. 我们通常将一个大项目分成许多“模块”项目，使我们能够在源代码管理下更快、更好地工作。我们要为整个DB使用一个大的"edmx“吗？
2. 由于我们有一个数据库设计器，我怀疑CodeFirst不是一种选择。那么，在数据库优先方法中使用EF值得吗？
3. 如果我们使用数据库优先方法，EF是否足够聪明，能够正确地检测所有关系，并准备好使用，而不需要我做更多的额外配置？(对于额外的配置，我的意思是我必须编写DataAnnotations，或者不得不编写DbContext)
4. 就我个人而言，我对使用sql设计数据库很有信心。我唯一的烦恼是当一个实体在我的类列表中被更改时，我必须更新所有的选择、删除、更新、插入脚本。EF会照顾我，但除了这个，我开始相信它会减慢我的表现，并最终减缓我的生产，因为我们不熟悉它。

你觉得值得吗？

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

Answer 1

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

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

谢谢大家的评论。

*在我再次直接进入ADO之前，我将给FluentData和Dapper一个机会。我会打开一个新的问题，所以如果你们想评论这两个轻ORMs，我会张贴链接稍后。

Answer 2

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

我想，你很快就会熟悉EF的用法，因此我不认为不熟悉将是一个长期的问题。

Answer 3

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

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

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