Measure. Really you can create performant applications with both but you can also screw up royally with both. Measuring your results is the only way to know for sure in your situation.
2 dev effort:
Personally I found the UI mapping possibilities of EF to be more RAD while developing. DAAB is great but it requires you to still write a lot of code or, if you're like me, try to create some custom T4 templates which generates code for you depending on
the database to reduce that amount of parrot work.
3 Application maintenance:
Either simply need to be put away in a dedicated layer so that swapping them out and replacing them becomes way easier and makes your application more maintainable. This is simply applying good architectural designs.
Grz, Kris.
Read my blog | Twitter Interested in Azure, ASP.NET (MVC), jQuery, WCF, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
Can you please explain little bit more on this .I mean what are the Pros and Cons in both .
EF gives you a great visual experience while designing your data access layer. DAAB takes more manual work (though you can optimize that by using custom made macros and T4 templates to generate things for you).
EF in 3.5 wasn't that exciting so if you're still stuck with 3.5 like me then opt for DAAB instead. EF became good to work with as of version 4.0.
And for more cons & pros: check both technologies out yourself, experiment with them and see what works for you and your team. Don't always rely on second opinions but make up your own experience and build on that.
Grz, Kris.
Read my blog | Twitter Interested in Azure, ASP.NET (MVC), jQuery, WCF, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
Marked as answer by srinivask on Nov 15, 2010 09:48 AM
IMHO, EF and similar approaches suffer a fundamental flaw: to have the metamodel in code. The DAAB I think stands at a lower level, on top of which you not only have templating: the metamodel can be in data, then you just need an administrator and a gui...
In .NET Framework 4.0 having huge improvements in entity-framework. I have done some R&D
work and find out some differences which provided me clear picture. I have specified some of them
below
.you can find complete post here ..
It is simply a query for which you tell the framework to keep the parsed tree in memory so it doesn't need to be regenerated the next time you run it. So the next run, you will save the time it takes to parse the tree.
Explanation :
The first time you run this query, the framework will generate the expression tree and keep it in memory. So the next time it gets executed, you will save on that costly step.
NO Support .Use Store Producers instead of hoc queries to improve the performance .
2
Model-First: Create your Entity Data Model and from that model generate DDL to create the database.
Model -Last
Create your database first and
Implement your Entities .
3
Developing vise verse possible (Entity to Tables ) and (Tables to Entity)
No Support
4
MVC with the Entity Data Source Control and the Entity Framework to quickly create data driven web.
Need to implement Business Entities manually
(takes more time )
5
LINQ Support
LINQ Support
5
Multiple related tables to a single entity and reduce code complexity.
No Support
7
Simplify Application Maintenance
By using entities in place of traditional data access code, changes to the underlying database schema do not always require changes to the application code.
Extend your applications to use more powerful editions of SQL Server or replace the database that
8
Automatically creates Complex types -Functions where as Enterprise library we have to create custom type
Need to implement manually
9
No need to write any code for Business entities
DAL framework, its very hard to come back and change later, no matter your architecture, because you'll have to redo a lot of code, be it well isolated or not
10
Re tuns Strong types
Returns Dataset/Datatable
which make heavy (needs to covert to strong types )
11
Re commanded development strategy
Either simply need to be put away in a dedicated layer so that swapping them out and replacing them becomes way easier and makes your application more maintainable. This is simply applying good architectural designs.
Same
12
Little bit slower when compare to Enterprise Library (store procedure mapping by default hock queries )
(we can tune to improve the performance [Support only 4.0)
13
Custom Code-Gen
Leverage T4, Text Template Transformation Toolkit, an easy, flexible and powerful Code Generation
tool that is fully integrated into the Visual Studio experience to customize the generation of POCO or Entity Classes.
Required Third party tools to generate business entities
14
Easily maintainable and changeable
Takes more time for changes
15
Model Driven Development
Separate the logical storage model of data from the way you model data within the application. The
Entity Framework provides a mapping between the application data model and the relational database model .
You are comparing apples with pears: EF is an O/RM, the DAAB is (only) a data access technology.
Moreover, a decent relational database (say, SqlServer) does an excellent job at optimizing and storing execution plans and, more generally, at handling data that is relational in nature; plus, you would model before implementing in that case too; plus,
there is no spaghetti code involved either, and I would say much less so... and so on.
srinivask
Member
94 Points
35 Posts
ADO.NET Entity Framework VS Micrsoft Data Access Application block
Nov 12, 2010 02:51 PM|LINK
Hi,
Which one gives better benefits among these two in the following areas
Performance.
Development Effort.
Application Maintenance.
Thanks in advance.
Entity framework
http://skonakanchi.blogspot.com/
XIII
All-Star
182709 Points
23464 Posts
ASPInsiders
Moderator
MVP
Re: ADO.NET Entity Framework VS Micrsoft Data Access Application block
Nov 12, 2010 02:59 PM|LINK
Hi,
1 Performance:
Measure. Really you can create performant applications with both but you can also screw up royally with both. Measuring your results is the only way to know for sure in your situation.
2 dev effort:
Personally I found the UI mapping possibilities of EF to be more RAD while developing. DAAB is great but it requires you to still write a lot of code or, if you're like me, try to create some custom T4 templates which generates code for you depending on the database to reduce that amount of parrot work.
3 Application maintenance:
Either simply need to be put away in a dedicated layer so that swapping them out and replacing them becomes way easier and makes your application more maintainable. This is simply applying good architectural designs.
Grz, Kris.
Interested in Azure, ASP.NET (MVC), jQuery, WCF, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
sreejukg
All-Star
27607 Points
4122 Posts
Re: ADO.NET Entity Framework VS Micrsoft Data Access Application block
Nov 12, 2010 03:11 PM|LINK
see this
http://stackoverflow.com/questions/615746/linq2sql-or-entity-framework-or-enterprise-library
My Blog
srinivask
Member
94 Points
35 Posts
Re: ADO.NET Entity Framework VS Micrsoft Data Access Application block
Nov 14, 2010 11:40 AM|LINK
Hi XIII,
Thank's for your response .Can you please explain little bit more on this .I mean what are the Pros and Cons in both .
Thank's in Advance .
Entity Framework
http://skonakanchi.blogspot.com/
XIII
All-Star
182709 Points
23464 Posts
ASPInsiders
Moderator
MVP
Re: ADO.NET Entity Framework VS Micrsoft Data Access Application block
Nov 14, 2010 12:20 PM|LINK
Hi,
EF gives you a great visual experience while designing your data access layer. DAAB takes more manual work (though you can optimize that by using custom made macros and T4 templates to generate things for you).
EF in 3.5 wasn't that exciting so if you're still stuck with 3.5 like me then opt for DAAB instead. EF became good to work with as of version 4.0.
And for more cons & pros: check both technologies out yourself, experiment with them and see what works for you and your team. Don't always rely on second opinions but make up your own experience and build on that.
Grz, Kris.
Interested in Azure, ASP.NET (MVC), jQuery, WCF, EF, MS SQL, ...
Keep the forums clean: report to the moderation team!
LudovicoVan
Star
9692 Points
1935 Posts
Re: ADO.NET Entity Framework VS Micrsoft Data Access Application block
Nov 14, 2010 02:44 PM|LINK
IMHO, EF and similar approaches suffer a fundamental flaw: to have the metamodel in code. The DAAB I think stands at a lower level, on top of which you not only have templating: the metamodel can be in data, then you just need an administrator and a gui...
-LV
srinivask
Member
94 Points
35 Posts
Re: ADO.NET Entity Framework VS Micrsoft Data Access Application block
Nov 16, 2010 06:04 AM|LINK
Hi all,
In .NET Framework 4.0 having huge improvements in entity-framework. I have done some R&D work and find out some differences which provided me clear picture. I have specified some of them below .you can find complete post here ..
http://srinivashelp.blogspot.com/2010/11/entity-frame-work-vs-enterprise-library.html
Entity Framework 4.0
Enterprise Library 5.0
1
compiled cached queries :
It is simply a query for which you tell the framework to keep the parsed tree in memory so it doesn't need to be regenerated the next time you run it. So the next run, you will save the time it takes to parse the tree.
Explanation :
The first time you run this query, the framework will generate the expression tree and keep it in memory. So the next time it gets executed, you will save on that costly step.
NO Support .Use Store Producers instead of hoc queries to improve the performance .
2
Model-First: Create your Entity Data Model and from that model generate DDL to create the database.
Model -Last
Create your database first and
Implement your Entities .
3
Developing vise verse possible (Entity to Tables ) and (Tables to Entity)
No Support
4
MVC with the Entity Data Source Control and the Entity Framework to quickly create data driven web.
Need to implement Business Entities manually
(takes more time )
5
LINQ Support
LINQ Support
5
Multiple related tables to a single entity and reduce code complexity.
No Support
7
Simplify Application Maintenance
By using entities in place of traditional data access code, changes to the underlying database schema do not always require changes to the application code.
Extend your applications to use more powerful editions of SQL Server or replace the database that
8
Automatically creates Complex types -Functions where as Enterprise library we have to create custom type
Need to implement manually
9
No need to write any code for Business entities
DAL framework, its very hard to come back and change later, no matter your architecture, because you'll have to redo a lot of code, be it well isolated or not
10
Re tuns Strong types
Returns Dataset/Datatable
which make heavy (needs to covert to strong types )
11
Re commanded development strategy
Either simply need to be put away in a dedicated layer so that swapping them out and replacing them becomes way easier and makes your application more maintainable. This is simply applying good architectural designs.
Same
12
Little bit slower when compare to Enterprise Library (store procedure mapping by default hock queries )
(we can tune to improve the performance [Support only 4.0)
13
Custom Code-Gen Leverage T4, Text Template Transformation Toolkit, an easy, flexible and powerful Code Generation tool that is fully integrated into the Visual Studio experience to customize the generation of POCO or Entity Classes.
Required Third party tools to generate business entities
14
Easily maintainable and changeable
Takes more time for changes
15
Model Driven Development
Separate the logical storage model of data from the way you model data within the application. The Entity Framework provides a mapping between the application data model and the relational database model .
No support for MDD
16
Advantages:
Support POCO templates (plain old clr objects)
Referred sites :
http://msdn.microsoft.com/en-us/magazine/cc188702.aspx
http://msdn.microsoft.com/te-in/magazine/cc163766%28en-us%29.aspx
http://channel9.msdn.com/Blogs/wriju/Using-Stored-Procedure-in-ADONET-Entity-Framework-40
http://msdn.microsoft.com/en-us/data/ff191186.aspx
http://msdn.microsoft.com/en-us/data/ef.aspx
http://channel9.msdn.com/Blogs/matthijs/C-40-and-beyond-by-Anders-Hejlsberg
http://msdn.microsoft.com/en-us/library/bb896279.aspx
http://jalpesh.blogspot.com/2010/08/entity-framework-40-bind-stored.html
Reffered Books:
1.Entity Framework 4.0 Recipes: A Problem-Solution Approach- By Larry Tenny, Zeeshan Hirani
2.Pro Entity Framework 4.0- By Jim Wightman, Scott Klein
enterprise Library vs. Enterpriselibrary
http://skonakanchi.blogspot.com/
LudovicoVan
Star
9692 Points
1935 Posts
Re: ADO.NET Entity Framework VS Micrsoft Data Access Application block
Nov 16, 2010 01:03 PM|LINK
You are comparing apples with pears: EF is an O/RM, the DAAB is (only) a data access technology.
Moreover, a decent relational database (say, SqlServer) does an excellent job at optimizing and storing execution plans and, more generally, at handling data that is relational in nature; plus, you would model before implementing in that case too; plus, there is no spaghetti code involved either, and I would say much less so... and so on.
-LV