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?
Best Answer
check this articalSome Advantages of NH over EF
- NH has 10+ id generator strategies (IDENTITY, sequence, HiLo, manual, increment, several GUIDs, etc), EF only has manual or SQL Server's IDENTITY;
- NH has lazy property support (note: not entities, this is for string, XML, etc properties), EF doesn't;
- NH has second level cache support (and, believe me, enterprise developers are using it) and EF doesn't;
- NH has support for custom types, even complex, with "virtual" properties, which includes querying for these virtual properties, EF doesn't;
- NH has formula properties, which can be any SQL, EF doesn't;
- NH has automatic filters for entities and collections, EF doesn't;
- NH supports collections of primitive types (strings, integers, etc) as well as components (complex types without identity), EF doesn't;
- NH supports 6 kinds of collections (list, set, bag, map, array, id array), EF only supports one;
- NH includes a proxy generator that can be used to customize the generated proxies, EF doesn't allow that;
- NH has 3 mapping options (.HBM.XML, by code, by attributes) and EF only two (by attributes, by code);
- NH allows query and insertion batching (this is because EF only really supports IDENTITY keys), EF doesn't;
- 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
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.
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.
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.
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.