使用Entity Framework处理大型项目

Question

我和我的团队即将启动一个新项目，目前我们正在探索和测试一些新技术（或者不那么新）。直到今天，我们一直使用经典的ADO与DBDataReaders，懒加载代理，并在某些情况下使用DataTables。我们的团队由3名开发人员和一名数据库设计师组成，我们的项目至少包含130个表格，而我们的新项目有可能增长到100个表格。

我最近两天一直在阅读并进行了一些简单的EF5测试，但仍无法决定是否应该使用它。以下是一些问题：

1. 我们通常将一个大项目拆分为许多“模块”项目，以便更好地在源代码控制下工作得更快更好。我们是否要为整个数据库使用一个大的“edmx”？

2. 由于我们有一个数据库设计师，我怀疑CodeFirst不是一个选项。因此，使用Database First方法值得吗？

3. 如果我们使用Database First方法，EF是否足够聪明以正确检测到所有关系，并准备好供我使用，而不需要更多的配置？（额外的配置指的是我必须编写DataAnnotations或必须覆盖DbContext）

4. 就个人而言，我很自信能够用SQL设计数据库。唯一的烦恼是当我的类列表中的实体发生更改时，我必须更新所有的select、delete、update、insert脚本。EF将为我处理此问题，但除此之外，我开始相信它会减慢性能，并最终减缓我的生产速度，因为我们不熟悉它。

你认为值得吗？除DataAnnotations和DbContext ovveride之外，是否有人使用普通的T4模板来创建表格（模式）呢？

- user2178369

---

你对 Entity Framework 提出了很多问题——这些问题的类型和问答格式都超出了常见问题解答（FAQ）所描述的范畴，建议限制问题的范围，并根据需要创建多个问题。在我看来，Entity Framework 是一项非常优秀的技术，学习该框架的努力无论如何都会受益，不管你的团队做出什么决定。 - IAbstract

感谢您的时间。摘要如下： 我试图尽可能快地呈现我的当前情况（困境）。 我不希望对我的每个问题进行深入分析。 - user2178369

你使用的是哪个版本的Visual Studio？VS2012允许您为同一个.edmx使用多个图表。 - John Saunders

这只是我的经验，不要在大型项目中使用EF。它有很多漏洞，你可能会花费很多时间来解决它们。只需要谷歌一下：EF漏洞！ - pylover

我强烈建议您查看使用Fluent API的EF 5。您仍然可以选择“DB First”，但代码和数据库之间的分离更加明显 - 不需要模型/图表。 - profMamba

Answer 1

1. 我绝对建议创建多个模型。你可以为每个模型选择要映射的表、视图和存储过程。
2. 优先考虑数据库，没问题的。
3. 如果数据库约束已经设置好，则EF会识别它们。你仍需要进行一些小修改，但总体来说，EF的性能还是相当不错的。
4. 使用EF会对查询性能产生轻微影响，但在大多数情况下这不是一个问题。只有少数情况下可能会出现无法接受的性能损失，你可以在必要时将自己的SQL注入到EF中以进行优化。

我认为，你会很快熟悉EF的使用方法，因此我认为陌生感不会成为长期问题。

- Dennis Traub

---

#2 是正确的，但在自定义模型或 POCO 方面有一定的注意事项。 - IAbstract

@IAbstract 是的，但考虑到在 OP 的情况下，替代方案似乎是使用 ADO.NET 和懒加载代理，这可能并不是一个大问题。 - Dennis Traub

我想补充一下，你可以同时获得代码映射和数据库优先的方法。只需使用“EF Power Tools”VS插件，并使用“反向工程代码优先”选项从现有数据库创建代码映射即可。在我看来，“代码优先”只是代码映射的一个愚蠢的名称。 - Patryk Ćwiek

Dennis，感谢您的时间， 我也考虑创建多个模型，但最终陷入了这样一种情况：在多个模型上有一些表出现了多次。 我不知道这是否是预期行为，还是我的设计出了什么严重的问题。 - user2178369

@SteliosKornelakis 我不确定我理解你的意思。在多个模型中有一些表并不是很重要（我希望这在相当复杂的情况下是成立的）。但我建议每个模块都有自己的edmx模型项目。即使您使用不同的命名空间，EF有时也会在一个项目中使用具有相同类名的多个模型时感到困惑。 - Dennis Traub

Answer 2

我决定不使用EF。 在大型项目中使用它存在风险，需要付出很多工作来使用它，可能会遇到错误和额外的开销。 我更喜欢编写更多的SQL代码并花费更多时间来维护，而不是处理生成的模型或检查SQL分析器生成的查询语句。 感谢大家的评论。 *在回到纯ADO之前，我将尝试FluentData和Dapper。 我将发布一个新问题，如果你们想评论这两个轻量级ORM，我稍后会发布链接。

- user2178369

---

我强烈建议您仍然使用Fluent API来查看EF 5。您仍然可以进行DB First，但代码与数据库之间的隔离更加明显-不需要模型/图表。以下是一些链接，演示如何使用Fluent API解决常见任务- 这里 和这里。 - profMamba

在我的公司，我们广泛使用SQL Server数据工具项目来管理各种数据库。在应用程序方面，我们使用EF DB first。它运行得非常好，迁移也可以通过SSDT轻松完成。 - Mike Bailey

你有没有尝试过NHibernate？我和你一样对Entity Framework有所了解。Entity Framework的基础架构非常复杂且不够灵活。但是NHibernate使用XML。 - bayramucuncu

Answer 3

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

如果数据库结构正在开发中，或者将来会经常变化，我会认为 EF 可能不适合你。

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

- pearcewg

---

如果您没有使用EF，并且更改了数据库结构，那么您就不需要做任何更改吗？ - user915331

我正在回答这个问题，试图提供帮助。你似乎有一个答案，也许你应该提交它。 - pearcewg

我没有完整的答案，但我对你提到的那一点非常确定，它并没有帮助。 - user915331

我会反过来说。如果你正在开发数据库，那么EF是一个福音，因为它可以帮助你进行数据库迁移。一旦你拥有了成熟的数据库，如果你发现需要增加性能的地方，你可以考虑编写裸SQL或存储过程，甚至在特定的性能关键部分使用Micro-ORM，如Dapper。 - crush