locked
What's the difference between datasets and the entity framework? RRS feed

  • Question

  • I'm somewhat new to .NET Datasets and the Entity Framework but it seems like typed datasets provide the same type of object layout as the entity framework.

    For example, using datasets I can have TableName.Field which seems to be exactly the same as with the Entity Framework.

    What's the difference and why should I use one or the other?
    Wednesday, July 29, 2009 2:17 PM

Answers

  • Good question. There are an enormous number of differences, so we'll start at the fundamental difference:

    DataSets give you a basic in-memory database that you can query and fill from a data source such as a database. Queries against datasets are executed against in-memory data.

    Entity Framework gives you a translation layer that translates LINQ queries to your database's SQL dialect. Queries against the EF ObjectContext are always executed against the database.

    Strongly typed datasets wrap your rows with named property accessorts.

    Entity Framework classes do not wrap rows - they have relationships to other classes, and, in .NET 4.0, can be plain old CLR objects that derive from "object". In addition, Entity Framework classes support inheritance and various mapping patterns, such as splitting a class's members across multiple tables, hiding join tabels with many-to-many relationships, and so on.

    On the down side, the entity framework can be more complex to program against for n-tier scenarios and asp.net scenarios, and has a higher learning curve. Which technology you pick depends on your skills and your needs...


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yichun_Feng Tuesday, August 4, 2009 10:22 AM
    Wednesday, July 29, 2009 7:51 PM

All replies

  • Good question. There are an enormous number of differences, so we'll start at the fundamental difference:

    DataSets give you a basic in-memory database that you can query and fill from a data source such as a database. Queries against datasets are executed against in-memory data.

    Entity Framework gives you a translation layer that translates LINQ queries to your database's SQL dialect. Queries against the EF ObjectContext are always executed against the database.

    Strongly typed datasets wrap your rows with named property accessorts.

    Entity Framework classes do not wrap rows - they have relationships to other classes, and, in .NET 4.0, can be plain old CLR objects that derive from "object". In addition, Entity Framework classes support inheritance and various mapping patterns, such as splitting a class's members across multiple tables, hiding join tabels with many-to-many relationships, and so on.

    On the down side, the entity framework can be more complex to program against for n-tier scenarios and asp.net scenarios, and has a higher learning curve. Which technology you pick depends on your skills and your needs...


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by Yichun_Feng Tuesday, August 4, 2009 10:22 AM
    Wednesday, July 29, 2009 7:51 PM
  • Thanks for the response.

    It's interesting that dataSet queries are performed against the in-memory database but EF queries are performed directly against the database.

    The downside to using datasets is that it seems to be all or nothing.  For example, if I want to get a list of customers that have a first name of "John" I either need to retrieve the entire database table and store it in-memory or write custom procedures to pull only the data I need.

    It sounds like with the EF framework that I can execute the same query but it will only grab the result set from the database (instead of grabbing everything and performing the search/query in-memory).

    Does that sound right?
    Thursday, July 30, 2009 10:36 AM
  • Thanks for the response.

    It's interesting that dataSet queries are performed against the in-memory database but EF queries are performed directly against the database.

    The downside to using datasets is that it seems to be all or nothing.  For example, if I want to get a list of customers that have a first name of "John" I either need to retrieve the entire database table and store it in-memory or write custom procedures to pull only the data I need.

    It sounds like with the EF framework that I can execute the same query but it will only grab the result set from the database (instead of grabbing everything and performing the search/query in-memory).

    Does that sound right?

    You got it
    Thursday, July 30, 2009 7:29 PM
  • Roughly - you always have the option of querying the objects that the entity framework has loaded into memory using LINQ to Objects by querying the ObjectStateManager in the ObjectContext. You can also implement a similar pattern using datasets, of course, by pulling in the data you need, and then executing in-memory queries against the dataset.

    Arguably, datasets offer a more natural in-memory querying mechanism.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, August 8, 2009 9:49 PM
  • I know this is an old post, but - I see a lot of criticism about ADO.Net and datasets which seems to be based on just this misunderstanding, and I can't resist putting in my 2p/cents  worth.

    Also numerous books on LINQ and EF attempt to show how much better these technologies are, by presenting comparisons with very poorly written ADO.Net dataset based code. 

    You really don't need to pull the entire table into the dataset first - with a table of any size, this would be plainly absurd. You can use parameterised queries, or construct the where clause in code on the fly if you need to. 

    Also you can often avoid joins / pulling duplicated data in hierarchical structures  by using a sequence of single-table queries in conjunction with well designed indexes. This technique is counter-intuitively faster than one  big join query (according to David Sceppa in his ADO book).

    Monday, April 16, 2012 1:14 AM
  • The downside to using datasets is that it seems to be all or nothing.  For example, if I want to get a list of customers that have a first name of "John" I either need to retrieve the entire database table and store it in-memory or write custom procedures to pull only the data I need.

    Does that sound right?

    No, it doesn't. With datasets you can create a custom query for your DataTableAdapter (in DataSet Designer), and use it to fill your table. For example, create a query method «GetJohns» with SQL-text «select * from myTable where name like "John %"», and then call this method in your code like this:

    myDataTableAdapter.GetJohns();

    I don't think that creating a custom query method using GUI Wizard (which can be done with couple of clicks) is so difficult that you call this «I need to write custom procedures». DataSets are quite easy-to-use in this scenario.

    P. S. Excuse me my English. It's not my native language.

    P. P. S. I know that I answer your question 4 years after you asked, but probably (even if it won't be useful to you), maybe it'll help someone who reads this.


    Sunday, July 7, 2013 4:57 PM