实体框架 - 它是否适合企业级应用程序？答案

【问题标题】：Entity Framework - is it suitable for Enterprise Level application?实体框架 - 它是否适合企业级应用程序？
【发布时间】：2011-08-04 15:33:37
【问题描述】：

我有一个 web 应用程序：

1 TB 数据库
200+张桌子
至少 50 个表，每个表有 1+ 百万条记录
10+开发者
1000 多个并发用户

本项目目前使用 Ad-Hoc Sql，由自定义 ORM 方案生成。我不支持自定义 ORM（缺少许多高级功能），而是考虑切换到实体框架。

我在一个较小的项目中使用了 EF 4.1（Code-First），它运行良好，但是对于上述更大的项目，它是否可扩展？

【问题讨论】：

标签： entity-framework entity-framework-4.1

【解决方案1】：

我（非常）同意 marvelTracker（和 Ayende）的想法。

这里有一些进一步的信息：

关键战略

使用 GUID 作为主键时，成本是众所周知的。它由 Jimmy Nilsson 描述，并已在 http://www.informit.com/articles/article.aspx?p=25862 上公开发布。 NHibernate 支持 GUIDCOMB 主键策略。然而，在 EntityFramework 中实现这一点有点棘手，需要额外的步骤。

枚举

EntityFramework 本身不支持枚举。直到六月 CTP 增加了对枚举的支持 http://blogs.msdn.com/b/adonet/archive/2011/06/30/walkthrough-enums-june-ctp.aspx 映射枚举的唯一方法是使用变通方法请查看：How to work with Enums in Entity Framework?

查询：

NHibernate 提供了多种查询数据的方法：

LINQ（使用 re-motion 的 re-linq 提供程序，https://www.re-motion.org/web/）
封装在查询对象中的命名查询
ICriteria/QueryOver 用于事先不知道条件的查询
使用 QueryOver 投影和聚合（在某些情况下，我们只需要实体的特定属性。在其他情况下，我们可能需要聚合函数的结果，例如平均值或计数）：
PagedQueries：为了避免让用户不堪重负并提高应用程序的响应能力，通常会将大型结果集分解为较小的结果页面。
将多个 ICriteria 和 QueryOver 查询组合到单个数据库往返中的多查询
分离的查询是应用程序部分中的查询对象，无法访问 NHibernate 会话。然后这些对象在其他地方通过会话执行。这很好，因为我们可以避免使用多种方法的复杂存储库。

ISession 的 QueryOver：

// Query that depends on a session:
premises = session.QueryOver<Premise>().List();

分离的QueryOver：

// Full reusable query!
var query = QueryOver.Of<Premise>();

// Then later, in some other part of ther application:
premises = query.GetExecutableQueryOver(session).List(); // Could pass IStateleSession too.

开源

NHibernate 在http://sourceforge.net/projects/nhcontrib/ 有很多贡献项目

该项目为 NHibernate（以及其他）提供了许多非常有用的扩展：

缓存提供程序（用于二级缓存）
没有默认构造函数的实体的依赖注入
全文搜索（Lucene.NET 集成）
空间支持（NetTopologySuite 集成）

支持

EntityFramework 附带 Microsoft 支持。 NHibernate 有一个活跃的社区：

另外，看看： http://www.infoq.com/news/2010/01/Comparing-NHibernate-EF-4

【讨论】：

【解决方案2】：

NHibernate 是您的最佳选择，因为它对复杂查询、二级缓存和优化支持有很好的支持。我认为英孚正在到达那里。如果您正在处理旧系统，NHibernate 是最好的方法。

http://ayende.com/blog/4351/nhibernate-vs-entity-framework-4-0

【讨论】：

【解决方案3】：

合适是一个有趣的术语。它可以使用吗？是的，您会发现许多非常适合快速应用程序开发的优秀特性。也就是说，它在某种程度上是一种半生不熟的技术，并且缺乏其前身 LINQ to SQL 的许多高级特性（甚至在其首次发布 3 年后）。以下是一些烦恼：

复杂的 LINQ 支持不佳
没有枚举属性类型
缺少 SQL 转换（解析 DateTime、解析 int 等）（尽管您可以通过模型定义的函数来实现这些）
SQL 可读性差
保持多个 ssdl/csdl/msl 资源独立于分片的问题（Code First 并不是真正的问题）
在不同的 ObjectContext 中运行多个并发事务的问题
分离实体场景的问题

也就是说，Microsoft 已经为此付出了很多努力，并希望随着时间的推移它会继续改进。我个人会花时间实现一个抽象良好的存储库/工作单元模式，这样您的代码根本不知道它正在使用 EF，如果有必要，您可以在将来切换到另一个 LINQ to DB 提供程序。

大多数现代 ORM 将比 ad-hoc SQL 更上一层楼。

【讨论】：