The danger of frameworks

I introduced Entity Framework (Code first) to my team in the beginning of this week. The other devs have not used it before, but as they are a Microsoft focused shop it was the only option other than ADO.NET. EF is a great tool but yet again I’ve got an example of how it blinds developers. It’s not just a Entity Framework problem, but frameworks in general.

The thing is that we have tables which represents our entities. Some of the tables are loosely coupled, but the EF Power Tools interpreted the relations as strong (thus interpreting some tables as junction tables). Most of the problems was sorted quickly by the dev. But one problem remained. And that was that cascading deletes did not work.

Instead of writing the delete queries manually the dev spent a day or two to fix the problem. I’m quite certain that a vanilla ADO.NET solution would have taken at most 30 minutes. What I’m saying is that ORMs works for most cases but not all. Unfortunately they blind developers. ORMs are so easy to use for the more common cases that the devs doesn’t seem to see that they waste hours on something that could have taken minutes with an alternative solution.

Use the right tool for the job.

  • I think it is not even a ORM problem per se but a problem whitch can come evident with any framework someone has to learn.
    Only an example:
    I once had to write a WPF app and i decided to use Caliburn.Micro (by the way an excellent framework) for the MVVM part. I had a problem to get a View wired up by the ViewModel and I spent a LOT of time trying all possible naming conventions and my final working solution was to write my own naming convention.
    If I compare the amout of time taken to find the right solution with the non MVVM solution I would say: it wasn’t worth the waste. But on the other side the framework gave me a lot which WAS worth the waste in this special domain.
    So I would say: The danger of Frameworks

    • You are of course right. Title changed.

      I love caliburn micro and it’s conventions. But sometimes I do the bindings manually so that I can do things that Caliburn can’t.

      The hard choice is to decide when to do it manually (i.e. or manual view binding) or the framework way.

  • baldric

    It is true that EF is less than perfect , but you have to consider the learning curve . Like the author says it’s the first time that they work with ef, so this is normal. The next time they develop a model with ef they’ll just apply the solution.
    In another topic micro-orms are having so much attention because of their speed, they are so much fast than ef when you try to make operations on a large scale.
    EF it’s a very nice tool and i use it a lot, but they have to improve the performance.

    • CodeFirst is a nice attempt to let the code drive the model. But in reality even experienced users still make compromises in the model so that CodeFirst will work. Letting the data layer drive the domain model will always make it harder to maintain when the application is a year or so.

      If you on the other hand do not make any compromises you’ll end up with a complex data layer as CodeFirst won’t fully support what you need to do.

      That’s why I prefer ADO.NET or a Mapping layer over an OR/M at any day. The gain you get from start with ORMs will always hunt you when the application have been maintained for a while after it’s been released.

      • Ricardo Gomez

        What about optimistic concurrency? Does EF helps in any way on web apps accesed by thousand of people at the same time? If no need of EF why to create it? 🙁

        • It depends on on how you build your application. If you have read and write model (CQRS) you can cache the read model with ease. In HTTP applications it’s really easy to cache pages, no need to do it in the data layer (at least not as the first option).

          I’m not saying that ORMs do not have their uses. They do. I do however find that the types of applications that I build benefit more from spending a little more time in the beginning to get it back when I have to maintain the application.

  • Matthew McCulloch

    Had a similar issue recently with trying to contort EF around an old badly formed (fks exist purely in developers mind type of thing) database that I needed to pull some data out of. Think I banged my head against my desk for a few hours until I finally realized I didn’t need to use EF in that repository simply because I’d used it in the rest of my repositories.

    30 minutes later I had some simple ADO statements written and a quick model mapper in my repository that spit the legacy data out as classes to the rest of the application just fine.

    Wish I had read this first, might have saved me some time and frustration!

  • $446191

    EF is just a terrible idea. EF serves no purpose. Seriously, it actually serves no purpose.
    Stop and look at what it actually brings to your applications architecture and you will quickly realize (if you have experience supporting applications in production) that EF buys you nothing but costs a great deal. The Enterprise Library is banned in my shop. There are far better, lighter weight, loosely coupled, and open source tools to use.

    There is one exception: if your app is trivial then EF and the EL are fine.

  • Callum Vass

    You’re right, use the right tool for the job. In this instance it seems that EF is a bad idea because of the loose coupling of your database structure. EF can’t interpret that out of the box without some configuration done first and seeing as your team is new to EF, it would have taken some time to learn how to do this.

    I’ve not used EF Power Tools before so I can’t comment on that part, but I think in your case a micro-ORM would have been better to write your queries in and map to an object. Something like Dapper, Simple.Data or ORM-Lite.