实体框架-适合企业级应用吗？

Question

我有一个web应用程序：

• 1TB DB
• 200+ tables
• 至少有50个表，1+百万记录每个
• 10+ developers
• 1000 s的并发用户H 210f 211

此项目目前使用自定义ORM解决方案生成的Ad。我不支持自定义ORM (它缺少许多高级功能)，而是考虑切换到实体框架。

我在一个较小的项目上使用了EF 4.1 (代码第一)，它运行得很好，但是对于上面一个更大的项目，它是否可伸缩呢？

Answer 1

我(非常)同意marvelTracker (和Ayende)的想法。

不过，以下是一些进一步的信息：

密钥策略

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

Enum

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

查询：

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

https://www.re-motion.org/web/)

• Named查询封装在查询objects

• ICriteria/QueryOver中，用于在advance

• Using QueryOver投影和聚合中不知道条件的查询(在这种情况下，我们只需要实体的特定属性。在其他情况下，我们可能需要聚合函数的结果，例如average或count):

• PagedQueries：，以避免压倒用户，并提高应用程序响应能力，大的结果集通常被分解成更小的results.

• MultiQueries页面，这些页面将几个ICriteria和QueryOver查询组合成一个数据库roundtrip

• Detached查询，这些查询是应用程序中的一些查询对象，而不需要访问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提供了一些非常有用的扩展(除其他外)：

缓存提供程序(用于对没有默认cache)

• Dependency搜索的实体进行2级constructor

• Full-Text注入(Lucene.NET integration)

• Spatial Support (NetTopologySuite integration)

)。

支持

EntityFramework提供了微软的支持。NHibernate有一个活跃的社区：

• https://stackoverflow.com/questions/tagged/nhibernate
• http://forum.hibernate.org/
• http://groups.google.com/group/fluent-nhibernate

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

Answer 2

NHibernate是您的最佳选择，因为它支持复杂查询、二级缓存和极大的优化支持。我想EF已经到了。如果您正在处理遗留系统，NHibernate是最好的方法。

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

Answer 3

合适是一个有趣的术语。它有用吗？是的，您将发现许多非常适合于快速应用程序开发的优秀特性。也就是说，这是一种半生不熟的技术，而且缺乏它自己的前身LINQ的许多高级特性(甚至在它第一次发布3年后)。以下是一些烦恼：

• 贫复合LINQ支持
• No Enum属性类型
• 缺失的SQL转换(解析DateTime、解析int等)(虽然您可以通过模型定义的functions)
• Poor SQL readability
• Problems来实现这些功能，但多个ssdl/csdl/msl资源可以独立于切分(实际上不是代码First)
• Problems在不同ObjectContext's
• Problems中运行多个并发事务的问题，具有独立实体场景

)。

尽管如此，微软在这方面付出了很大的努力，希望随着时间的推移，它将继续进步。我个人会花时间实现一个抽象的存储库/工作单元模式，这样您的代码就不知道它在使用EF，如果有必要，您可以在将来切换到另一个LINQ提供程序。

大多数现代的ORM将是从即席SQL的一个进步。