Comments on: Architecting Your Data Access Layer with the Entity Framework http://www.wadewegner.com/2009/06/architecting-your-data-access-layer-with-the-entity-framework/ From the whiteboard to the keyboard Sat, 04 Feb 2012 13:53:05 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Mohsin Khan http://www.wadewegner.com/2009/06/architecting-your-data-access-layer-with-the-entity-framework/#comment-1608 Mohsin Khan Sat, 19 Nov 2011 15:36:38 +0000 http://blog.wadewegner.com/index.php/2009/06/26/architecting-your-data-access-layer-with-the-entity-framework/#comment-1608 I am working on a web based project in DotNet4.0 where i want to implement 3 layer architechture and EF as data-access layer. EF gives me a rapid data connectivity and querying capability to the database. At the same time i don't want to create separate BusinessObjects [data traveller entities] throughout the 3 layers and infact want to use the same .edmx entities created automatically. There are around 50 tables in the database and creating entities foreach table is becoming very time-consuming. other thing is tables are not binded with any foreign key relationships so that is not mapped in .edmx as well. carrying different sets of data throughout the layers without custom entities is another major issue. I am working on a web based project in DotNet4.0 where i want to implement 3 layer architechture and EF as data-access layer. EF gives me a rapid data connectivity and querying capability to the database. At the same time i don’t want to create separate BusinessObjects [data traveller entities] throughout the 3 layers and infact want to use the same .edmx entities created automatically. There are around 50 tables in the database and creating entities foreach table is becoming very time-consuming. other thing is tables are not binded with any foreign key relationships so that is not mapped in .edmx as well. carrying different sets of data throughout the layers without custom entities is another major issue.

]]> By: sri http://www.wadewegner.com/2009/06/architecting-your-data-access-layer-with-the-entity-framework/#comment-208 sri Sat, 15 May 2010 14:08:37 +0000 http://blog.wadewegner.com/index.php/2009/06/26/architecting-your-data-access-layer-with-the-entity-framework/#comment-208 Excellent information, Can you upload the sample code..? Excellent information, Can you upload the sample code..?

]]> By: Reza Zareian Fard http://www.wadewegner.com/2009/06/architecting-your-data-access-layer-with-the-entity-framework/#comment-207 Reza Zareian Fard Sat, 13 Feb 2010 19:21:58 +0000 http://blog.wadewegner.com/index.php/2009/06/26/architecting-your-data-access-layer-with-the-entity-framework/#comment-207 Hi, It's really nice that you think on DAL and EF Architectural view but as kunal said would you please give us an example code? All the best Hi,
It’s really nice that you think on DAL and EF Architectural view but as kunal said would you please give us an example code?
All the best

]]> By: Kunal http://www.wadewegner.com/2009/06/architecting-your-data-access-layer-with-the-entity-framework/#comment-206 Kunal Mon, 24 Aug 2009 13:17:22 +0000 http://blog.wadewegner.com/index.php/2009/06/26/architecting-your-data-access-layer-with-the-entity-framework/#comment-206 Hello. Its nice architectural view of EF. But can you please explain the same with example? Thanks in advance Hello.
Its nice architectural view of EF. But can you please explain the same with example?

Thanks in advance

]]> By: Paul Rayner http://www.wadewegner.com/2009/06/architecting-your-data-access-layer-with-the-entity-framework/#comment-205 Paul Rayner Fri, 03 Jul 2009 14:32:24 +0000 http://blog.wadewegner.com/index.php/2009/06/26/architecting-your-data-access-layer-with-the-entity-framework/#comment-205 I have no experience with using the EF, so I am interested in learning more about its strengths and weaknesses. My personal preference is for high separation of concerns, and for (where possible) adherence to the dependency inversion principle by not having the domain/business layer depend on a concrete implementation of the data access layer. From what I understand, this is roughly what you mean by Full Encapsulation approach. I've been using NHibernate for two years now and have found it to be a framework that is very congenial to encapsulating data access completely away from the business layer - this allows me to have the business logic at the core of my system and treat persistence (data access) more as an infrastructure (secondary) concern than the foundational layer. In terms of how this works, in this approach POCO's have no dependencies on data access base classes - they typically do not inherit from a base class. Repository classes in the data access layer encapsulate NHibernate queries. But these Repositories are manifested in the business layer as interfaces, so no hard dependencies there, and full testability through unit tests of the business layer objects. Nhibernate has session management to support the unit of work pattern in the persistence of the business objects. There are certainly some things in NHibernate that sometimes make it a challenge to use, but overall I have been very pleased with what it can do. Can you adopt this type of approach with the EF? Also, can you elaborate more on how SQL queries end up spread through the layers in the Partial approach? This seems to me to be a major drawback. What type is "var db" in each approach? Is it an interface, or does that depend on which approach you are adopting? Thanks for the very interesting and thoughtful posting. Paul. <abbr><em>Paul Rayner’s last blog post..<a href="http://virtualgenius.spaces.live.com/Blog/cns!CC3C966FA733667C!744.entry" rel="nofollow">Agile 2009 – My Session Proposals</a></abbr></em> I have no experience with using the EF, so I am interested in learning more about its strengths and weaknesses.

My personal preference is for high separation of concerns, and for (where possible) adherence to the dependency inversion principle by not having the domain/business layer depend on a concrete implementation of the data access layer. From what I understand, this is roughly what you mean by Full Encapsulation approach.

I’ve been using NHibernate for two years now and have found it to be a framework that is very congenial to encapsulating data access completely away from the business layer – this allows me to have the business logic at the core of my system and treat persistence (data access) more as an infrastructure (secondary) concern than the foundational layer.

In terms of how this works, in this approach POCO’s have no dependencies on data access base classes – they typically do not inherit from a base class. Repository classes in the data access layer encapsulate NHibernate queries. But these Repositories are manifested in the business layer as interfaces, so no hard dependencies there, and full testability through unit tests of the business layer objects. Nhibernate has session management to support the unit of work pattern in the persistence of the business objects. There are certainly some things in NHibernate that sometimes make it a challenge to use, but overall I have been very pleased with what it can do.

Can you adopt this type of approach with the EF? Also, can you elaborate more on how SQL queries end up spread through the layers in the Partial approach? This seems to me to be a major drawback. What type is “var db” in each approach? Is it an interface, or does that depend on which approach you are adopting?

Thanks for the very interesting and thoughtful posting.

Paul.

Paul Rayner’s last blog post..Agile 2009 – My Session Proposals

]]> By: Daily Links for Monday, June 29th, 2009 http://www.wadewegner.com/2009/06/architecting-your-data-access-layer-with-the-entity-framework/#comment-204 Daily Links for Monday, June 29th, 2009 Mon, 29 Jun 2009 11:31:22 +0000 http://blog.wadewegner.com/index.php/2009/06/26/architecting-your-data-access-layer-with-the-entity-framework/#comment-204 [...] Architecting Your Data Access Layer with the Entity Framework | Architecting with .NET [...] [...] Architecting Your Data Access Layer with the Entity Framework | Architecting with .NET [...]

]]>