Entity Framework - is it suitable for Enterprise Level application?_问答_开发者

I have a web application with:

1 Terabyte DB
200+ tables
At least 50 tables with 1+ million records each
10+ developers
1000s of concurrent users

This project is currently using Ad-Hoc Sql, which is generated by custom ORM solution. Instead of supporting custom ORM (which is missing a lot of advanced features), I am thinking to switch to Entity Framework.

I used EF 4.1 (Code-First) on a smaller pr开发者_如何学Gooject and it worked pretty well, but is it scalable for a much larger project above?

I (highly) agree with marvelTracker (and Ayende's) thoughts.

Here is some further information though:

Key Strategy

There is a well-known cost when using GUIDs as Primary Keys. It was described by Jimmy Nilsson and it has been publicly available at http://www.informit.com/articles/article.aspx?p=25862. NHibernate supports the GUIDCOMB primary key strategy. However, to achieve that in EntityFramework is a little tricky and requires additional steps.

Enums

EntityFramework doesn’t support enums natively. Until June CTP which adds support for Enums http://blogs.msdn.com/b/adonet/archive/2011/06/30/walkthrough-enums-june-ctp.aspx the only way to map enumerations was using workarounds Please look at: How to work with Enums in Entity Framework?

Queries:

NHibernate offers many ways for querying data:

LINQ (using the re-motion’s re-linq provider, https://www.re-motion.org/web/)
Named Queries encapsulated in query objects
ICriteria/QueryOver for queries where the criteria are not known in advance
Using QueryOver projections and aggregates (In cases, we only need specific properties of an entity. In other cases, we may need the results of an aggregate function, such as average or count):
PagedQueries: In an effort to avoid overwhelming the user, and increase application responsiveness, large result sets are commonly broken into smaller pages of results.
MultiQueries that combine several ICriteria and QueryOver queries into a single database roundtrip
Detached Queries which are query objects in parts of the application without access to the NHibernate session. These objects are then executed elsewhere with a session. This is good because we can avoid complex repositories with many methods.

ISession’s QueryOver:

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

Detached 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.

Open source

NHibernate has a lot of contribution projects available at http://sourceforge.net/projects/nhcontrib/

This project provides a number of very useful extensions to NHibernate (among other):

Cache Providers (for 2nd-level cache)
Dependency Injection for entities with no default constructor
Full-Text Search (Lucene.NET integration)
Spatial Support (NetTopologySuite integration)

Support

EntityFramework comes with Microsoft support. NHibernate has an active community:

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

Also, have a look at: http://www.infoq.com/news/2010/01/Comparing-NHibernate-EF-4

NHibernate is the best choice for you because it has good support of complex query, second level cacheing and great support of optimizations. I think EF is getting there. If you are dealing with Legacy systems NHibernate is the best approach.

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

Suitable is an interesting term. Is it usable? Yes, and you'll find a number of nice features well suited toward rapid application development. That said, it's somewhat of a half baked technology, and lacks many advanced features of its own predecessor, LINQ to SQL (even 3 years after its first release). Here are a few annoyances:

Poor complex LINQ support
No Enum property types
Missing SQL Conversions (parse DateTime, parse int, etc.) (though you can implement these via model defined functions)
Poor SQL readability
Problems keeping multiple ssdl/csdl/msl resources independent for sharding (not really a problem with Code First)
Problems with running multiple concurrent Transactions in different ObjectContext's
Problems with Detached entity scenarios

That said, Microsoft has devoted a lot of effort to it, and hopefully it will continue to improve over time. I personally would spend time implementing a well abstracted Repository/Unit of Work pattern so your code doesn't know it's using EF at all and if necessary you can switch to another LINQ to DB provider in the future.

Most modern ORMs will be a step up from ad-hoc SQL.