实体框架对于多个网站和大型应用程序来说是一个糟糕的选择吗？

Question

场景：我们目前有一个网站，并且正在努力建立几个带有管理网站的网站。我们正在使用 asp.net-mvc、SQL Server 2005 和 Entity Framework 4。因此，目前我们有一个包含所有网站的单一解决方案，并且所有网站都使用相同的实体框架模型。该模型目前有 70 多个表，未来可能还会有更多……大约 400 个？

问题：实体框架模型在变大时会变慢吗？我已经阅读了很多文章，他们说与 ado.net 相比，由于额外的映射层，它非常慢？此外，我们曾想过拥有多个模型，但似乎这也是一种不好的做法，当我们不使用任何 ORM 时，LINQ 有用吗？

所以，我们只是好奇所有使用类似技术的大型网站是什么以及如何在使用像 EF 这样的 ORM 时取得良好的性能，还是他们从不选择 ORM？我还开发了一个 LINQ to SQL 应用程序，它有超过 150 个表，我们招致了巨大的启动损失，第一次加载时站点需要 15-20 秒才能响应。我很确定这是由于 LINQ to SQL ORM 的大量启动成本。如果有人可以分享他们对此的经验和想法，那就太好了？要遵循哪些最佳实践，我知道这取决于每个应用程序，但如果性能是一个问题，那么应该采取哪些最佳步骤？

Answer 1

我认为您当然可以让 EF4 以高性能方式处理具有大量表的数据库。也就是说，您肯定必须克服一些 EF 特有的障碍。

我不认为 LinqToSql 是一个好的选择，因为微软已经停止了大部分的增强。

您还考虑过哪些其他选择？ ADO.NET？休眠？存储过程？

我知道 NHibernate 可能无法快速为 400 个表建立 SessionFactory，但这只会在网站应用程序启动时发生一次，如果应用程序被大量使用，这种情况应该很少见。每个 Web 请求通常都有一个新的 Session，从会话工厂创建会话非常快速且成本低廉。

Answer 2

我对 EF 最大的担忧是事物的管理，如果您有多个模型，那么您突然需要进行多项工作来维护它们，确保您永远不会为正确的数据库更新错误的模型，或者反之亦然。目前这对我们来说是一个问题，而且看起来只会变得更糟。

就个人而言，我喜欢编写 SQL，而不是依赖于抽象之上的抽象。数据库了解 SQL，因此我对手工制作的存储过程或在某些情况下手工制作的 SQL 感到满意。这样做的一个巨大好处是我可以回复代码以查看它正在尝试做什么，并通过 c&p 将 sql 从日志中查看到 sql 查询编辑器中的结果数据。在我看来，这使得支持变得如此容易，它完全使您从一开始就使用 ORM 可能获得的任何程序员好处都无效（尤其是当 EF 生成绝对不可读的 SQL 时）。

事实上，想想看，ORM 给您的唯一好处是您可以更快地编写代码（当然，一旦您完成了所有设置并且不更改架构），最终，我不会'认为收益不值得付出代价，而不是当您考虑到我将大部分编码时间都花在思考我将要做什么时，因为'做'部分相对于设计、测试、支持和维护零件。

Answer 3

我没有给你一个明确的答案，但我找到了这个 SO 帖子：ORM performance cost，它可能会为你提供信息，特别是提到这个网站的第二高答案：

http://ormbattle.net/

我个人的经验是，对于我目前所见的任何 ORM 映射器，Joel 的 law of leaky abstraction 都非常适用。因此，如果您要使用 EF，请确保手头有可供优化的替代方案。