Dataset vs Entity Framework with stored procedures

Question

The whole question has been rewritten to be more clear..

New project design:

1. Sql Server 2012
2. Visual Studio 2012 .Net 4.5
3. Business logic will be implemented in stored procedures
4. ASP.Net Webforms
5. WCF SOAP XML Web Service to communicate with database using provided stored procedures by DBA
6. Entity Framework or Dataset

Here I can use Dataset - no problem, but I would like to know the advantage of Entity Framework over Dataset in more detailed explanation. I've been reading articles about entity framework, and I saw people had better experience using EF over dataset due to following reasons.

I would like to know if these are still advantages that I can obtain using EF in my case - database related actions are always done with stored procedures:

1. EF is a lot cleaner and much easier to maintain and program against. Queries against the EF ObjectContext are always executed against the database

2. Because the mapping between your objects and your database is specified declaratively instead of in code, if you need to change your database schema, you can minimize the impact on the code you have to modify in your applications--so the system provides a level of abstraction which helps isolate the app from the database. The EF can therefore replace a large chunk of code you would otherwise have to write and maintain yourself.(What if stored procedure design has been changed?)

3. The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes.

4. DataSets suck, especially in a WCF scenario (they add a lot of overhead for handling in-memory data manipulation) -> means EF with WCF is better in performance ?

Answer 1

1. EF is a lot cleaner and much easier to maintain and program against ->> can you elaborate?.. is this because of #2 below?

EF is an Object Relational Mapper (ORM) and will automatically generate objects related to your database schema as noted in #2. EF is an out-of-box abstraction for your data access layer and in the current version implements a repository pattern. This gives you benefits such as LINQ, object graph CRUD operations, and what the EF team deems as best practice for accessing data via .NET.

The out-of-box functionality and ease of integration with the database (specifically SQL Server) can provide easier to maintain and program against. However, there are situations where using an ORM may not be the best option and you should use prudent judgement. Here are some scenarios to think about not using an ORM (especially when your team lacks current knowledge of EF): limited data queries, non-complex application, comfortable writing or using your data access layer, your application deadline is aggressive, etc. See other options I noted below.

2. If you need to change your database schema, you can minimize the impact on the code you have to modify in your applications ->> what if parameters and returned fields of a stored procedure are changed? EF still minimize the impact?

Yes, EF generates based off of EDMX file which is simply an XML file of your database schema. This includes updating objects that map to your stored procedures (NOTE: this is not applicable if using code first until EF6 is released). You can alter a stored procedure and EF can take the updated schema and update your code. However, you will have to fix your code where you called EF stored procedures methods and the parameters have changed. You can also use something LINQ to SQL if you are uncomfortable with EF which will provide stored procedure calls as object methods.

3. DataSets suck, especially in a WCF scenario (they add a lot of overhead for handling in-memory data manipulation) ->> Can you explain more?

"DataSets suck" is obviously a generic statement. You use DataSets for what they are intended for which is dealing with data in memory using .NET. Since DataSets are in memory they are considered inefficient when doing simple CRUD operations. It is recommended to use stored procedures and data readers (be sure to close them when done reading data) for efficient data reads with SQL database.

There are other options besides EF out there:

1. Do it yourself - Write stored procedures, use data readers, and map to POCO objects

2. Use a Dynamic Library - Dapper, ServiceStack ORM Lite, Simple POCO, Simple Data, Massive

3. Use LINQ to SQL - Lighter weight data access layer (Only for SQL Server )

4. Other ORMs - NHibernate is a top choice.