Entity Framework 4 vs NHibernate

 

A lot has been talked about Entity Framework first version on the web (also on stackoverflow) and it is clear that it was not a good choice when we already have better alternative like NHibernate. But I can't find a good comparison of Entity Framework 4 and NHibernate. We can say that today NHibernate is the leader among all .NET ORMs, but can we expect Entity Framework 4 to displace NHibernate from this position. I think if Microsoft has really injected very good features in EF4 it can give good competition to NHibernate as it has Visual Studio integration, easier to work with and preference is always given to MS products in most shops.

EF4 has an out-the-box answer with regard to n-tier development, in "self-tracking entities". Nobody has released comparable code for NHib.

NHib has many features that have not been mentioned as being part of EF4. These include the second-level cache integration. It also has greater flexibility in inheritance mapping, better integration with stored procs / database functions / custom SQL / triggers, support for formula properties and so on. IMO it's basically just more mature as an ORM.

Update: I haven't used Entity Framework since version 4.0, so my answer can be outdated. I'm still using NH or pure ADO .NET in my projects. And I don't even want to look at what's new in EF since 4.0, because NH works perfectly.

Actually is pretty easy to compare them when you have used both. There are some serious limitations with EF4, I can name some which I encountered by my self:

EF4 problems:

  • Eager Loading and shaping the result : EF4 eager loading system (Include("Path")) generates improper SQL, with looping JOIN's , which will execute thousands(not literally) time slower for many-to-many relationships then hand written SQL (it's effectively unusable).
  • Materializer can't materialize associated entities : If you can think you can overcome previous problem by providing you own SQL query, you are wrong. EF4 can't materialize(map) associated entities from JOIN SQL query, it can only load data from one table (So if you have Order.Product, SELECT * FROM order LEFT JOIN Product will initialize only Order object, Product will remain null, thought all necessary data is fetched in query to init it ). This can be overcome by using EFExtensions community add-on, but the code you will have to write for this is really ugly (I tried).

  • Self-Tracking Entities : Many say that Self-tracking entities are cool for N-tier development including the top answer in this thread. Thought I haven't even give them a try, I can say they are not.Every input can be forged, you can't simply take the changes that user sends you and apply them to data base, why not give the user direct data base access then? Any way you will have to load the data user is about to change from DB, check that it exist|not exists do permissions checks etc etc. You can't trust user on the state of entity he is sending to server, you will anyway have to load this entity from DB and determine it's state and other things, so this information is useless, as do Self-Tracking entities unless you do a private trusted n-tier system for internal use, in which case maybe you could give just plain DB access. (Thats my thoughts about ST Entities and N-tire, I'm not very expericned in N-Tier, so it can change, if I misunderstood something here comment it)

  • Logging, Events, integrating business logic: EF4 is like black box, it do something and you have no idea what it do. There is only one event OnSavingChanges where you can put some business logic you need to run before something happens with DB, and if you need to apply some changes to business objects before something happens you will have to dig in ObjectStateManager, and this is really ugly, code can become huge. If you for example using Repository pattern and what to be notified on changes made to DB in clean object way, you will have hard time doing this with EF.

  • Extensibility: All EF code is private and internal, if you don't like something (and you will not like a LOT if you are serious about EF using), no way you will change this in easy way, In fact I'm sure it's easer to write you own ORM from scratch (I did) then make EF work as you need. As example take a look at EFExtensions source, it's based on extensions methods, and different "hacks" to make EF little more usable, and the code is pretty ugly (and it's not authors fault, when everything in EF is private this is the only way to extend it).

    • I can continue to write bad things about EF and how painful it was for me to work with it for like 20 pages, and maybe I will.

    What about NHibernate? It's absolutely different level, it's like comparing PHP to C#, EF4 is like in Stone-age, it's like EF is 10 years behind then NHibernate in development progress, and in fact it is, Hibernate was started in 2001. If you have free time to learn and switch on Nhibernate, do it.

    Here's the thing. NHibernate and Entity Framework are really for two different audiences, in my mind. NHibernate would be my choice in building a system with complex mappings, formulas, and constraints (basically anything enterprise). If I wanted to hit-the-ground running with simple data access, I would use Entity Framework or LINQ-to-SQL. NHibernate doesn't have a clear "drag-and-drop" experience quite like EF. Both have their strengths and drawbacks. Comparing them apples-to-apples, frankly, gets you nowhere.

    链接地址: http://www.djcxy.com/p/20318.html

    上一篇: 列表vs设置与NHibernate中的包

    下一篇: 实体框架4与NHibernate