实体框架是多个网站和大型应用程序的不良选择吗？

Question

情景：我们目前有一个网站，正在与管理网站建立几个网站。我们正在使用asp.net-mvc，SQL Server 2005和Entity Framework 4.因此，目前我们有一个解决方案，所有网站和所有网站都使用相同的实体框架模型。该模型目前有70多个表格，将来可能会有更多......大约400个？

问题：当实体框架模型变得更大时，它是否会变慢？我已经阅读了不少文章，他们说这是因为与ado.net相比，附加的映射层，它相当慢？另外，我们想过有多个模型，但似乎这也是一个不好的做法，当我们不使用任何ORM时，LINQ是否有用？

所以，我们只是好奇所有使用类似技术的大型网站是什么以及如何使用类似EF的ORM来获得良好的性能，或者他们从不选择ORM？我还参与了一个有超过150个表的LINQ to SQL应用程序，并且我们发现了一个巨大的启动惩罚，站点在第一次加载时需要15-20秒来响应。我很确定这是由于LINQ to SQL ORM的启动成本很高。如果有人可以分享他们的经验和想法，那会很棒吗？遵循哪些最佳实践，我知道这取决于每个应用程序，但如果性能是一个问题，那么最佳步骤是什么？

Answer 1

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

http://ormbattle.net/

我个人的经验是，到目前为止，我见过的任何ORM映射器，Joel的law of leaky abstraction都适用。因此，如果您打算使用EF，请确保您手头有优化的替代方案。

Answer 2

我认为你肯定可以使用具有大量表的数据库以高性能的方式工作。也就是说，你肯定必须克服一些特定于EF的障碍。

我认为LinqToSql不是一个很好的选择，因为微软已经停止对其进行大量增强。

您考虑过哪些其他选择？ ADO.NET？ NHibernate的？存储过程？

我知道NHibernate可能无法快速为400个表建立SessionFactory，但这只会在网站应用程序启动时发生一次，如果应用程序被大量使用，这应该是相当罕见的。每个Web请求通常都有一个新的会话，并且从会话工厂创建会话非常快速且便宜。

Answer 3

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

就个人而言，我喜欢编写SQL而不是依赖于abstration之上的抽象。数据库知道SQL，因此我对手工制作的存储过程或某些情况下手工编写的SQL感到高兴。这样做的一个巨大好处是我可以回复代码以查看它正在尝试做什么，并通过c＆amp; p sql从日志到sql查询编辑器查看结果数据。在我看来，这使得支持变得如此简单，它使得使用ORM的程序员的好处完全无效（特别是当EF生成绝对不可读的SQL时）。

事实上，想想看，ORM给你的唯一好处就是你可以更快地编码（一旦你完成所有设置并且当然没有改变架构），最终，我不会我认为这样做的好处是值得花费的，而不是当你考虑到我花费大部分编码时间考虑我要做什么时，因为'做它'部分相对较小，而不是设计，测试，支持和维护零件。