How about performance of linq to sql, Entity Framework and NHibernate?

Question

I was learning this ORM because think this is good technology for most projects. But most employers required acquirement of ADO.NET and SQL.

This ORM not will use in high-loaded system (like popular web-sites)? In which types of projects this ORM will be useful? Are highly loaded projects using ORM?

Answer 1

If you want the best possible performance, don't use an ORM. That said, not all parts of an application need the best possible performance and good ORMs (custom built or off the shelf) significantly increase development speed.

I'm not a big fan of the ORMBattle website, but searching for questions including that term on StackOverflow will give you additional information to read about .NET ORM performance:

http://www.google.com/search?q=site:stackoverflow.com+ormbattle

For instance:

http://stackoverflow.com/questions/1982567/testing-custom-orm-solution-performance-overhead-how-to

http://stackoverflow.com/questions/1501312/orm-esp-nhibernate-performance-for-complex-queries

Good ORMs result in very little overhead (on top of ADO.NET) and the performance will be just fine in the large majority of cases.

A good ORM will allow you to easily "drop to the metal" (i.e. get closer to raw SQL performance) when you need extra performance.

Answer 2

All depends on you requirements and your architecture.

ORMs are evils when you have an reporting system and a very good for simple logic. If will implement a Repository Pattern may be will achieved a good performance.

But, as I said all depends on your requirements and architecture.

Have a look at CQRS (Command-Query Responsibility Segregation) here, this is an interesting approach of system design.

Answer 3

Have a look at Foundations of Programming, this is where i started.

I like to use an ORM where I have a Relational Db with a domain model (objects to be persisted). I find it to save time on development and provide cleaner code.

regarding your post about jobs, I noticed this too. However I can only speculate the answer is they still have so many .Net developers who are still learning this (ORM) there for the frameworks are not in their production systems.

I have noticed a number of Consultancy companies which seem to be using ORMS (if you are one of these companies and you do not use an orm, please correct this, I based it on your technical blogs)

IMeta (Offers Commercial support for NHibernate) UK Engine Room Apps (they offer lessons and write apps using Nhibernate) UK EMC2 (they did the whocanhelpme on codeplex)

HTH

bones

Answer 4

ORMs can certainly be performance killers. I've measured performance of Entity Framework (v1) and LINQ to SQL against ADO.NET (both datasets and datareaders). EF performance was simply unacceptable, especially in web apps where data contexts would be created and discarded very frequently. LINQ to SQL wasn't too bad, but wouldn't qualify for a high-performance application. The difference between the two is that EF is a two-layer model, without generated code to optimze the mapping between layers. LINQ to SQL is a single layer, and doesn't offer nearly as much customization; the trade-off is that LINQ queries map more closely to the relational model, so there is much less overhead.

The concept of an ORM is certainly valuable; it results in much cleaner code at the application level. But there's no such thing as a free lunch. I'm currently writing a custom ORM that maps a single data model onto both SQL Server and Oracle, with the ability to switch between servers with a simple app config setting. However, there's no LINQ IQueryable provider, and all queries are written or generated as dynamic SQL and run as ADO.NET queries. All database interaction is interfaced to the application as method calls for specific operations, and IEnumerables of entity classes returned as results. Performance is within 10% of straight ADO.NET coding, but that level of performance was a requirement from the start of the project.

While the core components of this ORM could be used in any project, the only way to get ORM and high performance is to avoid any on-the-fly mapping, either between layers (as EF does) or translating LINQ into SQL. (It's very painful to write that, because I dearly love LINQ, but the mapping cost is too much. I did make sure that LINQ to Objects works both within the ORM and in application usage with the results.)