The Joel on Software Discussion Group (CLOSED)

I see a lot of people bashing the Entity Framework from Microsoft, why is this?  I've started to look at it and it seems pretty neat, and finally an ORM from Microsoft so we don't have to use things like NHibernate, but a fully-integrated tool (Sue me, but I like things integrated tightly into my IDE and platform rather than plugging in various things to make a Frankenstein).

The only issue I don't like is that it seems like they are ignoring LINQ now when it's only just came out, and that sucks because from what I've seen LINQ is very, very cool.

I don't want to jump into learning LINQ if it's going to be obsolete quickly, but I also don't want to learn EF if the verdict is that it sucks for real use.  Can someone explain what's wrong with it?

I tried it, and found it to be too cumbersome. The tool in the IDE to define the mapping was not very flexible, and if you want to roll your mapping files by hand you have to edit three files as I recall. I was excited about it initially, but it was too much of a hassle. I found nHibernate and other O/R mappers to be easier to use.

I like nHibernate better, XML configuration files are more elegant than designer-generated (and bloated) files.

Also nHibernate has been around for a while, it's pretty stable and mature, has a community around it, etc.. Entity Framework has a lot to prove yet.

There's a lot of promise in EF, and it seems to be the "favored" data access tool at MS right now, but there's a pretty wide consensus that it's not quite baked yet.

I played w/ it for a while, and the initial "reverse-engineer your DB" experience is pretty cool.  I found that the glow faded pretty quickly, though, when I started trying to change things - as others have pointed out, the interface is challenging.  I'd be willing to chalk this up to my personal ineptitude, but I've heard from a lot of other people who've had similar experiences.

If you'd like to try something a little lighter, I really like SubSonic - it doesn't try to be so smart that it gets tangled up in itself.  It's not really an ORM tool -- it's too light-weight for that , but I think that's part of the appeal.

It's not that bad.  I still like nHibernate better.  You can edit nHibernate mappings by hand.  EF mappings are pretty gnarly.

I have one acronym to say: LLBLGEN.

Easy to use, and it has Linq support. Best money our department has ever spent.

"You can edit nHibernate mappings by hand. "

If it's that easy for you to map between OO and Set-based structures then you are doing something wrong. Either your OO isn't really OO, or your set-based structures are very poorly designed - or both. That's why the EF, LINQ, xHibernate, and all of these other ORM disasters are bad - they foster and encourage poor design.

Don't worry, you know what they say about Microsoft data access frameworks; if you don't like it just wait 12 months for the next one.

It could also be that the mappings are trivial.

LLBLGEN sucks. I asked them why LLBLGEN doesn't let the user take advantage of ADO.Net's async methods and the guy was like "It's too hard."

With Linq to SQL it was easy to run queries async (and multiple ones, at the same time) the benefit of which is that you're getting called back on an IOCP thread, when using the ADO.Net async methods.

*********
If it's that easy for you to map between OO and Set-based structures then you are doing something wrong. Either your OO isn't really OO, or your set-based structures are very poorly designed - or both. That's why the EF, LINQ, xHibernate, and all of these other ORM disasters are bad - they foster and encourage poor design.
*********

+ 6 zillion to that.

I can't count the number of times we have had to compromise the DB design because Hibernot can't parse sound design.

"It could also be that the mappings are trivial."

If that's the case then they shouldn't be needed in the first place. I've never worked on a non-trivial OO project with a set-based data storage layer where one could be trivially mapped to the other. OO and set-based structures are completely different paradigms of design, with very few and mostly insignificant correlations between the two.

If a project is so trivial that the mappings line up then one really shouldn't be using layered structures in the first place.

"I can't count the number of times we have had to compromise the DB design because Hibernot can't parse sound design. "

Why isn't throwing out Hibernate an option? I ask because in a thread like this the only people I hear of not using ORMs are those that are just dead set against them, like me.  Maintaining other people's use of them has caused me more pain than I would like to admit to, and it's not all due to my lack of familiarity with the thing, either.

I don't think I've ever heard once from somebody saying "Yeah, we threw out Hibernate because it couldn't do the job." People either compromise the database, as you stated, or turn their reasonably well architected application into some kind of monster. But Hibernate hangs around, doing it's thing. I'm sure there have been people that tossed it out on its ear, but maybe I just haven't heard them say so?

A few issues with v1 of Entity Framework

1. Makes Test Driven Development difficult
2. Visually building model is good for small models, but is cumbersome for large models. Doing it manually like nHibernate is much easier, but that may not be apparent until you have significant experience doing it both way.
3. Chokes on large data models.
4. Is suspect in team programming environment where multiple developers need to work on the model.

"Why isn't throwing out Hibernate an option?"

Because ORM is a fad, and rejecting a fad just isn't cool or exciting. Once enough people get burned by the bad designs it fosters it will become the next GOTO of programming lore. Until then a bunch of really bad software systems will be created that will eventually need to be tossed or rewritten.

"People either compromise the database, as you stated, or turn their reasonably well architected application into some kind of monster."

This statement is so true. About 2 yrs ago, we choose NHibernate to be the ORM for our "great and powerful/do-it-all" start-up software. - It was a great success in the begining when we were still in beta, but as we added more modules, thousands of customers (with their own portals), web services (wcf - mistake), custom functionality (reports, fields, commands), we made a lot of poor design decisions because we had to abide by NHibernate's rules.

Needless to say by this time - developer morale kept heading south.

After 2yrs, our database schema looked so ugly, and ridiculous because of NHibernate.

"The only issue I don't like is that it seems like they are ignoring LINQ now when it's only just came out, and that sucks because from what I've seen LINQ is very, very cool."

Do you mean LINQ to SQL, or LINQ in general? EF objects are absolutely queryable using LINQ.

LINQ to SQL is it's own thing, and shouldn't be confused with Language INtegrated Query that acts as a general query framework for lots of things (objects, XML, Sql Server, EF, etc...)

If it's a fad, then what is the best way to handle data in an application?  I've heard nothing but good things about ORMs and how much better they make writing apps... if they're a fad and all of these issues arise, then what's the solution?

"if they're a fad and all of these issues arise, then what's the solution?"

http://en.wikipedia.org/wiki/Design_by_contract

The interaction between disparate paradigms is best done through negotiated contracts that both sides agree to honor. Without this the two paradigms get distorted trying to accommodate one another.

@Wayne:
"...if they're a fad and all of these issues arise, then what's the solution?"

You can use three other approaches depending on the problem at hand:

a) Use generic classes that model the relational objects directly (like TDataset in Delphi/CDataset in MFC) instead of your application objects. So instead of having a TCustomers class that needs to be mapped to a relational table, you would simply use a TDataset to hold the customers data in your app.

b) Use serialization. Define a TCustomers class in your app with methods that allow the objects of that class to be deserialized and serialized to any datastore of your choice, relational or not.

c) Use an object oriented database (OODB) or even a  roll your own persistent object database (POD) if you feel up to it.
 
ORMs try to solve the impendance mismatch problem in a generic way that doesn't always work out best for many applications.

Hibernate solves some problems and introduces others.  This is what I learned after converting my entire web site from using Apache DBUtils to Hibernate.

Pros:
1.  Once mapping is complete, it becomes trivial to add a member variable to an object and have it persisted to your database.
2.  Caching of result sets is fairly trivial.
3.  Data access layer remains fairly clean.
4.  Bi-directional relationships are easy to implement.
5.  Guaranteed to be working with objects instead of ids, etc.

Cons:
1.  Mapping to legacy databases is non-trivial and often leads to compromises in object model.
2.  Performance is difficult to optimize. 
3.  Poorly designed object graphs can force too many objects to load into memory.
4.  Caching of objects is difficult.  Telling hibernate to cache something doesn't always mean it will be cached.
5.  Managing mapping files / annotations is difficult ... not at first, but after 6 months it's easy to forget why you did x, y, and z.  I suppose this can be said about all programming though.  I find it especially difficult with Hibernate mappings though.
6.  Need to introduce another framework ... Spring.  Hibernate by itself requires you to manage transactions, which leads to more boiler plate code, which is what you tried to eliminate by using Hibernate in the first place.
7.  Transaction configuration ultimately moves to XML, which makes it difficult to understand what some code does without consulting some XML file.

Hardest part was mapping to legacy database.  I made some compromises in database model to make Hibernate happy. 

Ultimately, I like hibernate, but it's not the silver bullet some people claim.  Instead of debugging your own framework, you end up debugging someone elses' framework.

I did look at EF briefly however a friend of mine did some decent research on this and his response was not good. Basically his opinion was that it is extremely good for small database and minor database tasks however as the database schema grows bigger and complex, it becomes too much cumbersome to handle things via EF. Plus I am not sure how Stored Procedures would fit into picture.

One of the things I was trying to do with EF is to build these models dynamically i.e. not knowing which database to connect to  begin with. I tried and I tried and then I left :).

Cheers!!!

We use nHibernate in conjunction with Castle ActiveRecord.

I wont lie, I hate it. Its overcomplicated, cumbersome and misses a very simple concept - relational data is relational data, trying to bash it in to an OO model is (IMHO) so problematic its not even funny. It was sold to me as the second coming and it isn't, its not even close. If I could remove it from our apps I would.
I totally agree with the previous replies about it compromising design. We've already been running into performance problems with it.

If you are doing a simple CRUD website then its worth looking at, any further than that and I'd run a mile from it.

I haven't tried using EF yet, but have read a bit about it. Until I use it in anger I'll withold judgement.

Oh no ... that's another technology stack Microsoft has taken from Java. They're becoming more like us each day except that you can't trust the technology to be stable enough to be around for more than a few years whereas it doesn't happen with Java.

However, I have to admit MSFT's miles ahead with UI. We're only now starting to use component-based Web UI (JSF has been officially adopted as a standard) and finally, I'm getting back to familiar component-based UI like VB or VC++ or Swing.