Do you remember this post ?
Now Microsoft gave us a step-by-step guide : POCO Templates for the Entity Framework
Fantastic!!!
Now we need a good soul starting the integration with NHibernate to generate POCO and mappings.
There will be a little difference:
The POCO template generates Entities that supports change notification.
Well… I’m here again over the same matter… again performance.
This post is about some thoughts after this thread on nhusers list and not strictly a comparison between NHibernate vs EntityFramework.
To compare performances I have used again the same environment and the same domain used in this post but, this time, with 50 companies having 50 employees having 50 reports; total entities 127550.
So far I’m NOT an expert in EntityFramework (I’m waiting for EF4) so I have used the same configuration Gergely Orosz have used in his performance test. The code used for NHibernate is the same of the previous post and the code used, to materialize all entities, for EntityFramework is the follow:
using (var ctx = new EFContainer())
{
var companies = from c in ctx.EFCompanySet select c;
foreach (var company in companies)
{
company.Employees.Load();
foreach (var employee in company.Employees)
{
employee.Reports.Load();
}
}
}
The results of the test are
Store data seconds: 209,25 ( 209249 miliseconds)
Read data seconds: 57,77 ( 57773 miliseconds)
Store data seconds: 24,29 ( 24287 miliseconds)
Read data seconds: 24,6 ( 24603 miliseconds)
Which is your conclusion ? NHibernate is faster than EntityFramework ? NHibernate is slow because the materialization of 127550 entities took 24.6” ?
That is what you are seeing ?
The first time I chose NHibernate was because:
On what is based your daily work ?
TDD? DDD? code maintainability? business request? YAGNI? easy to implements? XP? dead-line? elegant-code solutions? performance? sprint?
If the performance is the most important concept why you are not programming using assembler instead C# ?
Are you applying only one of these concepts or your work is a continuous balance of each ?
What I’m seeing, in many teams, is that, for various reasons, we are loosing the most important concept: the balance of each.
In front of the question “why you chose this solution ?” many times the answer is “because the dead-line is tomorrow” or “because it is the minimal code to pass my test” and so on. The worst results is not the mere answer itself but what will happen after… perhaps when you have a performance issue. If you saw that the solution you have chose does not satisfy the expectance why, rethink the whole solution, shouldn’t be an option ?
Have a quick look to your toolbox perhaps you having the right tool to solve the issue. What ? using that tool the code is not elegant ? it will be more hard to maintain ? it is more hard to implements ?… and? which is the main target of that specific task ?
As you can see above a persistent-layer based on ORM is not the right tool to perform bulk operations, is not the right tool to perform massive data mining, is not the right tool to provide data for OLAP cube… this mean that a persistent-layer based on ORM is not a good tool ? absolutely NOT my friend, that only mean that in your application you have a lot of different tasks and you should choose the right tool for each specific task…have a look to your toolbox!!!
If you want LINQ2NH or you are planning to use LINQ2EF please don’t say me that you are defining Repository like this
public interface ICustomerRepository
{
Customer GetCustomerById(string id);
IEnumerable<Customer> FindByName(string name);
void AddCustomer(Customer customer);
}
How much complicated can be the professional life of a persistent layer developer ?
“Entity Framework 4.0 will use T4 (Text Template Transformation Toolkit), which makes customizing Code Generation easy, flexible and powerful, and the experience is also fully integrated into Visual Studio.”
So flexible that you can generate all you want ?
Fantastic!!!
Hopefully, soon, NHibernate will have even a graphic designer fully integrated with VisualStudio to generate mappings and classes and directly developed by Microsoft.
Awesome how things are changing, no ? ;-)
Perhaps, in few months, we will see something more useful than we saw sofar.
Entity Framework 4.0 will allow POCOs and lazy-loading of POCOs.
Microsoft will show us his muscles, soon, even in ORM.
