Version 5.0 will have it...
time to read 3 min | 401 words

Dave's seem hit directly on a nerve with this post:

I can’t agree on his the only “compelling technical advantage” [Linq for Entities vs NHibernate] comment. Perhaps true from the standpoint of what ships with Orcas release of VS, but as a long term vision I think we need to seriously consider this as a positive step.

Let me take this apart for a second.

Linq for Entities (Orcas) is going to ship (earliest) at the end of this year. Sometime in the future (probably 2010), there will be a new version that will have compelling technical advantage over what NHibernate offers today. Therefor, you should go with Linq for Entities.

Q.E.D ??

He goes on to say that NHibernate is an ORM and Linq for Entities is not, therefor the comparision is flawed.

That said, EDM (Entity Data Model) is a logical representation of a data model. The framework will permit various “services” to be attached to this model such as domain objects/models containing behavior (which is what we want to test and test-drive after all) replete with LINQ queries, reports, mock and test data generation, entity aggregation type service endpoints, etc.

NHibernate as a simple Object Relational Mapper works, and has tremendous benefits, but that is not even scratching the surface. You can use NHibernate to do quite a bit more. From AOP for your entities, full fledged IOC container, contextful manipulation etc.

I am using NHibernate in a project when it is actually spitting out different objects based on the customer that is currently working with the system. So I have a base entity Salary, and I have NorthwindSalary, SouthwindSalary, etc. When I need to calculate a salary, I just fetch it from the database, NHibernate is taking care of me getting the correct entity (not service) from the database, which contains the logic for calculating the salary.

I would like to hear about the features that Dave talks about, and what scenarios are they useful for.

Tweet Share Share 1 comments
Tags: