none
Is the Entity Framework really as good as it looks? RRS feed

  • Question

  • I hope this isn't too controversial, but I've only just started looking at EF4, and I am amazed at how easy it is to use. I'm using the old painful way of writing loads of SQL, and loads of code to grab DataSets and DataTables. I've barely scratched the surface of EF4, but can see myself never writing any code again! OK, so that's an exaggeration, but it certainly looks like it would save an enormous amount of time and effort.

    Which brings me to my question. When you get into serious usage, it is as easy as it looks? I am very happy to use a framework that's going to make my life easier, but I have bad memories of previous attempts to do this sort of thing (web classes and data bound controls in VB6 stick out as two painful sagas for example), and I don't want to invest too much time and effort learning EF4, only to find out later that it's not the right tool.

    I've seen ideas before that looked fantastic for management demos, but when you tried to use them in earnest, you ended up fighting the framework, and writing as much code to get around the default behaviour as you would have done if you'd written the whole thing from scratch.

    Anyone any comments? I'm not trying to be cynical, I'm just trying to find out as much as I can before investing a lot of time and effort.

    Thanks for any replies.

    Wednesday, July 7, 2010 2:17 PM

Answers

  • Hello Mr. Yossu

    I believe no technology is ever perfect, and EF is no exception. If you are considering EF, I suggest you to do a pilot project (with a partial list of requirements from your REAL project), and assess the pros and cons. I believe there is no one shoe that fits all.

    About performance, any LINQ-based models (like LINQ-TOSQL) are slower than their native counter parts. If you want to compare EF with a DataReader, then the DataReader might be faster, since a DataReaderis a native ADO.NET object, while EF is an abstraction over DataReader. This applies to any abstraction, and every abstraction comes with a cost. As Architects and Developers, it's our responsibility to balance the cost with gains (Scalability, Maintainabiliy etc). I believe this applies to any new technology.

    Here are some of the issues I faced with EF (version 1, .NET 3.5). Some have been addressed in EF2 (.NET 4.0):

    • Lack of foreign keys. Some 3rd party controls rely on these. Solved by extending the generated Entity objects.
    • Serialization (and de-serialization) of large Entity graphs over the wire. Solved by loading only the needed parts of an Entity graph.
    • ObjectContexts are expensive to create, and can not be cached.
    • Some 3rd party aspx controls load data (as part of their life cycle) multiple times. This might not be apparent with native stuff like DataReaders and DataSets, but the difference was noticeable with large EntitySets.
    • Som of our application access multiple databases. EF does not support cross-database modelling.

    Despite these, I still love EF, partly for the great Architecture, and mostly for doing away with our legacy home-grown data access layers. Not that they are bad - they are just outdated.

    Thursday, July 8, 2010 8:48 PM

All replies

  • Yossu,

    As you know both traditional Dataset and Entity framework works on disconnected architecture. We can do all forward and backward operations i.e DDL and DML operations.

    After I started using the entity framework, reduced the lengthy and dirty code using with DATA SET.

    Here the framework gets the copy of database structure and data to code level using EDMX file. The DDL and DML operations doesnot run untill and unless method save calls.

    Frequently it does not touches the database for retrieval or updating. it junks the total data at UI side and process it and then saves it.

    By this process server round trips reduces and code get optimized and performable.

    Instead of writing Data Access Layer, EF is giving facility just to call the methods which does all the DDL and DML operations and also it controls the concurrency (Pessimistic Concurrency and Optimistic Concurrency )

     

     

     


    Regards Bhargava Vangapally, Architect, Software Architectural Group.

    [[KINDLY MARK AS ANSWER IF IT HELPS TO RESOLVE YOUR QUERY]]

    Wednesday, July 7, 2010 4:40 PM
  • Hello Bhargava,

    So it sounds like you're pretty pleased with it? I must say that (apart from one glaring bug I found), I'm also very impressed with it, but wanted to hear the opinions of people who've been using it for longer.

    Thanks for the reply.

    Wednesday, July 7, 2010 6:50 PM
  • I used EF in a couple of (n-tier) projects, and I am happy with it. I know there are limitations and shortcomings, but I am sure EF Team is aware and will be providing more in next versions.

    I found that based on my personal observations, EF is suitable for you if:

    1. Your app is mostly doing simple CRUD operations.
    2. You do not need bulk-update operations.
    3. Your app uses a single database.
    4. Your App is not a performance-critical OLTP application.
    Thursday, July 8, 2010 2:27 PM
  • Hello Srinivas,

    I used EF in a couple of (n-tier) projects, and I am happy with it. I know there are limitations and shortcomings, but I am sure EF Team is aware and will be providing more in next versions.

    Yeah, but I don't want to commit myself to something that has limitations and shortcomings right now! Was there anything apart from the four issues you mention below?

    I found that based on my personal observations, EF is suitable for you if:

    1. Your app is mostly doing simple CRUD operations.
    2. You do not need bulk-update operations.
    3. Your app uses a single database.
    4. Your App is not a performance-critical OLTP application.

    That fourth one bothers me a lot. Are you saying that EF is slow, or that it uses a lot of memory? What performance issues did you see with it?

    Thanks

    Thursday, July 8, 2010 8:02 PM
  • Hello Mr. Yossu

    I believe no technology is ever perfect, and EF is no exception. If you are considering EF, I suggest you to do a pilot project (with a partial list of requirements from your REAL project), and assess the pros and cons. I believe there is no one shoe that fits all.

    About performance, any LINQ-based models (like LINQ-TOSQL) are slower than their native counter parts. If you want to compare EF with a DataReader, then the DataReader might be faster, since a DataReaderis a native ADO.NET object, while EF is an abstraction over DataReader. This applies to any abstraction, and every abstraction comes with a cost. As Architects and Developers, it's our responsibility to balance the cost with gains (Scalability, Maintainabiliy etc). I believe this applies to any new technology.

    Here are some of the issues I faced with EF (version 1, .NET 3.5). Some have been addressed in EF2 (.NET 4.0):

    • Lack of foreign keys. Some 3rd party controls rely on these. Solved by extending the generated Entity objects.
    • Serialization (and de-serialization) of large Entity graphs over the wire. Solved by loading only the needed parts of an Entity graph.
    • ObjectContexts are expensive to create, and can not be cached.
    • Some 3rd party aspx controls load data (as part of their life cycle) multiple times. This might not be apparent with native stuff like DataReaders and DataSets, but the difference was noticeable with large EntitySets.
    • Som of our application access multiple databases. EF does not support cross-database modelling.

    Despite these, I still love EF, partly for the great Architecture, and mostly for doing away with our legacy home-grown data access layers. Not that they are bad - they are just outdated.

    Thursday, July 8, 2010 8:48 PM
  • Thanks for the replies.

    I'm going to try and learn a lot more about EF, and put it to the test. It certainly seems to be easier to use, so as long as I don;t run into too many problems, I'll stick with it!

    Thanks again

    Sunday, July 11, 2010 2:57 PM
  • Good luck!  :-)   If you have any problems on EF4, welcome to the EF forum here!  

     

     

    Good day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, July 12, 2010 7:13 AM
    Moderator