none
What is the future of ADO.NET given EF? RRS feed

  • Question

  • Now please consider this:

    what is the future of Entity Framework?  And what does that mean to the traditional "Cobbs" way of using relational databases, and using DataSets/DataTables/DataViews?  I say this after skimming through the book "Programming Entity Framework" (2009) by Julia Lerman.

    Seems like the "drag and drop" approach of Karli Watson as outlined in his excellent book "C# 2005 Databases" is the future (because EF sure looks very OO and drag-and-drop to me).

    I also note that SQL to Linq has been deprecated--I wonder if datasets will follow in a few years time.  I wonder if using datasets and the traditional "Cobbs" way of making sure you access tables in a certain way, starting say with the parent table and moving to all dependent child tables, and being very particular about your UPDATE/INSERT/DELETE order, will be handled in the future "behind the scenes" in a [Serializable] manner.

    I'm all for EF if it eventually does that, in particular after struggling with this problem in the last few weeks (until I discovered Watson's 'drag-and-drop' way).

    RC
    Sunday, May 3, 2009 10:11 PM

Answers

  • Hi *,

    I think the best way is to look at EF Design blog and also TL20 Entity Framework Futures presentation from PDC.
    Jiri {x2} Cincura
    • Marked as answer by RonConger09 Friday, May 15, 2009 8:02 PM
    Saturday, May 9, 2009 4:27 PM
  • One thing I see:  I'm not entirely sure that the EF way of mapping is much different than the dataset way of mapping.  I see in Lerman's book an attempt is made to show that the EF mapping (CSDL) different from the storage/logical mapping (SSDL), but to me it's almost like trying to make an artificial distinction.  For 99% of the time it seems safer to stick with the CSDL = SSDL (but I'm just getting into EF).

    RC

    Hi *,

    the mapping in EF is really some mapping. Your conceptual model may look completely different from store shape - consider just inheritance, table splitting, etc. And not only this. With CSDL you're abstracting from store. You don't think "hey this is foreign key", no, it'a navigation property. And if there will be EF provider i.e. for Cache (which is OO database), there would be no FK at all (yes, you can use SQL do access Cache objects too). But you'll just change the store and mapping. The rest, the CSDL and your application, will stay untouched. Similarly with M:N associations.
    OTOH you may or may not use all of this. If you create 1:1 mapping from your database, you're very close to CSDL = SSDL.

    And that's just a tip of the iceberg. Maybe with new mapping abilities of EF in next version we'll be able to do more rich mapping than today. And not only relational databases or databases at all. EF, although it's primarily focused on databases is able to work with XML store or any other ADO.NET and EF ready store.
    Jiri {x2} Cincura
    Saturday, May 9, 2009 4:34 PM

All replies

  • One thing I see:  I'm not entirely sure that the EF way of mapping is much different than the dataset way of mapping.  I see in Lerman's book an attempt is made to show that the EF mapping (CSDL) different from the storage/logical mapping (SSDL), but to me it's almost like trying to make an artificial distinction.  For 99% of the time it seems safer to stick with the CSDL = SSDL (but I'm just getting into EF).

    RC
    Monday, May 4, 2009 10:34 PM
  • Hi *,

    I think the best way is to look at EF Design blog and also TL20 Entity Framework Futures presentation from PDC.
    Jiri {x2} Cincura
    • Marked as answer by RonConger09 Friday, May 15, 2009 8:02 PM
    Saturday, May 9, 2009 4:27 PM
  • One thing I see:  I'm not entirely sure that the EF way of mapping is much different than the dataset way of mapping.  I see in Lerman's book an attempt is made to show that the EF mapping (CSDL) different from the storage/logical mapping (SSDL), but to me it's almost like trying to make an artificial distinction.  For 99% of the time it seems safer to stick with the CSDL = SSDL (but I'm just getting into EF).

    RC

    Hi *,

    the mapping in EF is really some mapping. Your conceptual model may look completely different from store shape - consider just inheritance, table splitting, etc. And not only this. With CSDL you're abstracting from store. You don't think "hey this is foreign key", no, it'a navigation property. And if there will be EF provider i.e. for Cache (which is OO database), there would be no FK at all (yes, you can use SQL do access Cache objects too). But you'll just change the store and mapping. The rest, the CSDL and your application, will stay untouched. Similarly with M:N associations.
    OTOH you may or may not use all of this. If you create 1:1 mapping from your database, you're very close to CSDL = SSDL.

    And that's just a tip of the iceberg. Maybe with new mapping abilities of EF in next version we'll be able to do more rich mapping than today. And not only relational databases or databases at all. EF, although it's primarily focused on databases is able to work with XML store or any other ADO.NET and EF ready store.
    Jiri {x2} Cincura
    Saturday, May 9, 2009 4:34 PM
  • hello everyone, this topic is 3+ years old.

    has anything changed since 2009?

    for new Enterprise Level Software development using .NET 4.5 on SQL Server 2012, should we use ADO.Net or EF/DbContext ? We need access to all underlying features of the database platform, maximum performance and control over the SQL.

    I personally find EF with Code First + DbContext API both easy and hard to use - at the same time!

    I find ObjectContext (*without* DbContext API) is too much code and too much complexity, I might as well stick with ADO.Net (correct me if I am wrong please).

    To get the most from the database with DbContext I still end up using a lot of native SQL (SqlQuery and ExecuteSqlCommand, with SqlParameters).

    I could do it all in either ADO.Net or DbContext. Which data access to choose in year 2013?

    I am getting an *impression* that most of Microsoft R&D in Data Access is going towards EF, is it possible ADO.NET will eventually be deprecated in favour of EF ? Should I favour EF DbContext ?

    thanks


    Yuri Budilov

    Friday, June 21, 2013 2:39 AM