Question

我的网络应用程序包含：

1 Terabyte DB
200+桌
每个
10多位开发人员
1000个并发用户

该项目目前正在使用由自定义ORM解决方案生成的Ad-Hoc Sql。我不打算支持自定义ORM（缺少很多高级功能），而是考虑切换到Entity Framework。

我在一个较小的项目中使用了EF 4.1（Code-First）并且它工作得很好，但它是否可以扩展到上面一个更大的项目？

Answer 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查询组合到单个数据库往返中的MultiQueries
分离的查询，它是应用程序部分中的查询对象，无法访问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

Answer 2

NHibernate是您的最佳选择，因为它支持复杂查询，二级缓存和优化支持。我认为EF正在那里。如果您正在处理Legacy系统，NHibernate是最好的方法。

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

Answer 3

适合是一个有趣的术语。有用吗？是的，您会发现许多非常适合快速应用程序开发的功能。也就是说，它有点半生不熟的技术，并且缺少其前身LINQ to SQL的许多高级功能（即使在首次发布后3年）。以下是一些烦恼：

复杂的LINQ支持不佳
没有枚举属性类型
缺少SQL转换（解析DateTime，解析int等）（尽管可以通过模型定义的函数实现这些）
SQL可读性差
保持多个ssdl / csdl / msl资源独立于分片的问题（代码优先没有问题）
在不同的ObjectContext的
分离实体方案的问题

尽管如此，微软已经投入了大量精力，并希望它会随着时间的推移而不断改进。我个人会花时间实现一个很好的抽象存储库/工作单元模式，所以你的代码根本不知道它使用EF，如果有必要，你可以在将来切换到另一个LINQ to DB提供者。

大多数现代ORM都是ad-hoc SQL的升级版。

实体框架 - 它适用于企业级应用程序吗？

3 个答案: