21

I am looking to implement an ORM into our system. We currently have many tables with lots of horrible data and stored procedures. I've heard using an ORM can slow the system down. Does anyone know which ORM is better on speed and performance using Queries created in the C# code and mapping to stored procedures?

Thanks

EDIT:

The project will use existing tables that are large and contain a lot of data, it will also use existing stored procedures that carry out complex tasks in a SQL Server DB. The ORM must be able to carry out transactions and have high performance when running the existing stored procedures and querying the current tables. The project is web based and will use WCF web services with DDD. I can see that EF is a lot easier to use and has greater support but if NH the most suitable option?

Funky
  • 12,890
  • 35
  • 106
  • 161
  • 1
    How big a project are we talking? Few hundred queries, few thousand? Are you optimizing preemptively? Nothing is going to be as fast as a direct query, or something like Dapper.NET but could still be used reasonably depending how you code it. – Brad Christie Aug 01 '13 at 15:45
  • possible duplicate of [Entity Framework 4 vs NHibernate](http://stackoverflow.com/questions/1639043/entity-framework-4-vs-nhibernate) – Paddy Aug 01 '13 at 15:51
  • 1
    Take a look at the following: http://stackoverflow.com/questions/699792/is-orm-slow-does-it-matter – David Tansey Aug 01 '13 at 15:54
  • ...and this too: http://java.dzone.com/articles/martin-fowler-orm-hate – David Tansey Aug 01 '13 at 15:54
  • 1
    @Paddy Yes but between EF4 and EF6 there was lots of changes – glautrou Aug 01 '13 at 15:54
  • 3
    NHibernate > Entity Framework. It's not even worth considering EF. – Phill Aug 01 '13 at 17:06
  • 1
    Please keep in mind that when working with ORM, performance will mostly depend on the way you will write your queries. I saw many people telling me that ORMs were slow and when I had a look on the way they tested it I understood immediately what was wrong! `context.Customers.Include("Orders").Include("OrderLines").Include("Products")` ;-) – MaxSC Aug 02 '13 at 07:59
  • 1
    EF4 was not too great. EF5 and above CAN give you up to 800% performance increase CAVEAT, ONLY IF YOU USE .NET 4.5 ! Old benchmarks are worthless! – Tom Stickel Nov 21 '13 at 17:33
  • Any clear cons to using n-hibernate? – RayLoveless Jun 04 '14 at 16:04
  • ef 6 and lower performance killer https://stackoverflow.com/questions/28543293/entity-framework-async-operation-takes-ten-times-as-long-to-complete – Firo Jun 13 '22 at 15:16

5 Answers5

11

The Entity Framework is constantly implementing new features and everything is automated in your project. It is very easy to use Entity Framework, extend and refactor your code. Visual Studio integrates it (Code-First, Database-first, Entity-First...) like a charm. Windows Azure makes easy to deploy and change it. Moreover Visual Studio can generate all your CRUD pages in 3 clicks.

I would suggest you use EF but it depends of your project. Can you give us more details about it?

You can find lots of comparison charts on Google, for example this one explains performance and this one differences.

EDIT:

Can you quantify the number of users in your application?

When you use Database-First in EntityFramework it is very easy to import and use stored procedures, for NHibernate it quite simple as well. Note that if you use a lot of stored procedures and not a lot of simultaneous users the choice of a ORM between those two may not be so crucial.

Also don't forget the performance of a tool is often based on the way to use it. If you misuse the ORM (e.g. async, lazy/eager loading, base classes, ...) the performance will drastically drop.

Perhaps you can instal both of them, look at how they work and check at their roadmap (e.g. Entity framework) to check at the evolution and interest.

Pradeep
  • 3,258
  • 1
  • 23
  • 36
glautrou
  • 3,140
  • 2
  • 29
  • 34
  • 5
    With Fluent NHibernate there's no need to create mapping files! – danyolgiax Aug 01 '13 at 15:52
  • True, thanks for spotting this, I am developing old projects and at this date Fluent NHibernate didn't exist so I have to create mappings manually. – glautrou Aug 01 '13 at 16:01
11

check this artical Some Advantages of NH over EF

  1. NH has 10+ id generator strategies (IDENTITY, sequence, HiLo, manual, increment, several GUIDs, etc), EF only has manual or SQL Server's IDENTITY;
  2. NH has lazy property support (note: not entities, this is for string, XML, etc properties), EF doesn't;
  3. NH has second level cache support (and, believe me, enterprise developers are using it) and EF doesn't;
  4. NH has support for custom types, even complex, with "virtual" properties, which includes querying for these virtual properties, EF doesn't;
  5. NH has formula properties, which can be any SQL, EF doesn't;
  6. NH has automatic filters for entities and collections, EF doesn't;
  7. NH supports collections of primitive types (strings, integers, etc) as well as components (complex types without identity), EF doesn't;
  8. NH supports 6 kinds of collections (list, set, bag, map, array, id array), EF only supports one;
  9. NH includes a proxy generator that can be used to customize the generated proxies, EF doesn't allow that;
  10. NH has 3 mapping options (.HBM.XML, by code, by attributes) and EF only two (by attributes, by code);
  11. NH allows query and insertion batching (this is because EF only really supports IDENTITY keys), EF doesn't;
  12. NH has several optimistic control strategies (column on the db, including Oracle's ORA_ROWSCN, timestamp, integer version, all, dirty columns), EF only supports SQL Server' TIMESTAMP or all
Muhammad Nasir
  • 2,126
  • 4
  • 35
  • 63
7

Both are great solutions, although I personally think NHibernate is better for an inherited database.

There are some things that are clearly better in NHibernate, such as second-level caching support. Documentation is probably a bit sparser than EF, but if you're willing to go through the learning curve, NHibernate gives you a lot more power.

FluentNHibernate is great for typed mapping of classes to underlying tables but there are some places you will just have to revert to XML mappings. There is a new competing API from NHibernate itself however, and I have not checked it out yet (the above blog post mentions it).

If you want to rely on VS tooling support, EF is better. However there will be some magic sometimes (for e.g. EF can use reflection to even populate private properties of an object, NHibernate does not do that; this is a strength or a weakness depending on how you see it). EF also works well with other Microsoft supplied-frameworks (for e.g. RIA services). I also like EF-auto migrations (when you use code-first).

If you want more power in your hands and want to be able to fine-tune how things work with clear separation of concerns (ORM does only what the ORM should do), NH seems to be better. However, it is a bit irritating to make all the properties virtual for NH to be able to access them.

I have used both and it can get a bit clunky either ways sometimes to generate the sql you want; in those 5-10% cases, drop down one more level and use a micro-orm like Dapper, Massive or Petapoco.

EDIT:

NHibernate too can populate private properties, seemingly, so this was just ignorance on my part.

Tim
  • 5,435
  • 7
  • 42
  • 62
Roopesh Shenoy
  • 3,389
  • 1
  • 33
  • 50
6

EF 5 or 6 on .NET 4.5 is one sure way to increase performance, don't expect any speed improvement with EF 5 on .NET 4.0 this is documented by Microsoft. (We have another issue with poorly written LINQ statements too).

In General, if performance is high priority, you can't beat ADO.NET with Stored Procedures. You simply cannot. Added ORM, adding and IOC container... how much testing for performance do you want to do?

Spin up a few VM's with JMETER and hit a server with EF and hit another with NHibernate, You just force JMETER to make enough calls to URLS and test the amount of concurrent users and you should see where your bottleneck are.

Tom Stickel
  • 19,633
  • 6
  • 111
  • 113
  • 3
    Stored procedures give no more advantage for simple select statements, since all modern DBMS remember properly parameterized SQL queries and execute them with the same query plan, like a stored procedure. Stored Procedures are good if you need procedural elements, such as loops, control elements, variables etc. – Erik Hart Dec 31 '13 at 19:07
  • What exactly is a simple select statement. "Select simple1, simple2 from my simpleTable" ? Well, what if that table has 10 millions rows ? By definition this is a "simple select statement" however the backend table is flippin huge then it is generally best to put in a proc. I love linq statements, but that whole trend of everyone replacing sprocs with linq statements didn't end up proving to be that wise. Many sites were crawling and a lot of effort had to be done to fix. – Tom Stickel May 13 '16 at 22:08
  • Views are better than price for data access. Then.you use ef over the view and still get composability. – Matthew Whited Jun 02 '17 at 22:17
5

It may be worth adding here that Entity Framework has issues when attaching disconnected graphs and is missing functionality such as merge in Nhibernate. You can address it with other plugins, but not there out of the box. Here is a link to the feature on Codeplex requesting better support for working with disconnected entities, and there is some further discussion.

Mickey Puri
  • 835
  • 9
  • 18
  • The lack of .Merge in EF is a deal breaker for some. The OP should research this. "Entity Framework Merge". Google or Bing it. And you'll see the big snapfu. – granadaCoder Apr 24 '14 at 13:46