Upload
wade-wegner
View
39.169
Download
1
Tags:
Embed Size (px)
DESCRIPTION
This presentation highlights three ways in which to use the ADO.NET Enterprise Framework in conjunction with your DAL: 1) EF == DAL, 2) Encapsulation of EF, and 3) Partial Encapsulation of EF.
Citation preview
ADO.NET Entity Framework & Your Data Access Layer
Wade WegnerArchitect EvangelistMicrosoft [email protected]://www.architectingwith.net/http://www.twitter.com/wadewegner
Agenda
• What is the ADO.NET Entity Framework• How do you structure your DAL?– EF == DAL– Full Encapsulation– Partial Encapsulation
• ADO.NET Entity Framework 4.0• Existing Questions
Object Relational Mapper
• What does it do?– Persistence– Querying– Manages transactions– Manages concurrency
• It’s a tool– CRUD– Query model– Mapping
Entity Framework
• What does it do?– Persistence– Querying– Manages transactions– Manages concurrency
• It’s a tool– CRUD– Query model– Mapping
The Entity Framework is an O/RM
Business Logic
Data Access Logic
User Presentation
Data Sources
The ultimate question
• Where does this go?
var apartments = from a in db.Apartments where a.State == “IL” select a;
Separation of Concerns
• High Cohesion• Loose Coupling
What if there was no DAL?
• Is the EDM our DAL? • EF Entities? Are these our business objects?
Data Transfer Objects (DTO’s)• What if we wrote LINQ queries directly in our
business layer?– Separation of Concerns?• High cohesion?• Loose Coupling?
Option 1: Entity Framework as a DAL
Data Access
UI Presentation
Business
MSLCS SS ADO.NET Entity Client
Entities
var db = new AdventureWorksEntities(); var activeCategories = from category in db.ProductCategory where category.Inactive != true orderby category.Name select category;
var bo = new CategoryBusiness(); bo.Load();this.categoryGridView.DataSource = bo.ActiveCategories;
Business Objects
Forms
ADO.NET Object
Services
Entity Framework as a DAL
• Pros– Excellent Isolation from DB Schema– Independence from RDBMS– Object Services: Identity & Change Tracking– Full query comprehension over CDM in business logic
• Cons– Pre-.NET 4.0, “Object First” is not well support scenario– Pre-.NET 4.0, Entities are not very pure (not POCO)– Can’t easily switch ORM– Data validation support is limited.
Validation & Business Logicpublic string Phone{ get { return this._Phone; } set { this.OnPhoneChanging(value); this.ReportPropertyChanging("Phone"); this._Phone = DataClasses.StructuralObject.SetValidValue(value, true); this.ReportPropertyChanged("Phone"); this.OnPhoneChanged(); }}
public partial class Customer{ partial void OnPhoneChanging(string value) { if (value.Length < 7) MyCustomErrorHandler.SetError(this.EntityKey,
"Invalid Phone Number"); }}
Is the Entity Framework the lastDAL technology you will use?
Encapsulate
Why Encapsulate?
• Separation of Concerns• Testability• Embed additional logic• Performance/Control– Control ObjectContext Lifetime– Control SQL Generation– Eager Loading
• How can we do this and still keep the power of the Entity Framework?
Encapsulation Approaches
• Full Encapsulation– EF Entities are merely a DTO used in your data
access layer.– ObjectContext is a Data Access Component
• Partial Encapsulation– Expose Queryable Objects– Encapsulate ObjectContext
• Hybrid– Mix & match as appropriate
Option 2: Full Encapsulation
• Return an instance/collection of Custom Class• Pros– Simplified Queries– POCO Objects – ORM & RDBMS Agnostic, No EF References– Discrete set of SQL Queries
• Cons– No change tracking or identity management– Additional Object Materialization– No query composition: secondary LINQ queries are just
enumerating.
Option 3: Partial Encapsulation
• Three techniques– IEnumerable– IQueryable– ObjectQuery
• Pros– Full benefits of CDM
• Query composition• Simplified queries (Navigation vs. joins)• Some independence from ORM• Object Identity & Change Tracking
• Cons– Use of EF Entities has implications on Business Layer.– What are all my SQL Queries? Hard to answer.
Three DAL Options
• EF == DAL• Full Encapsulation• Partial Encapsulation
Entity Framework 4.0
• Development Approaches– Model first development– Testability
• Architectural Concerns– Persistent Ignorance (e.g. POCO)– Application Patterns (Repository and UnitOfWork patterns)– N-Tier applications
• Improvements– Customization of code generation– Pluralization and singularization, lazy loading, SPs– Customizing queries– SQL generation readability & query improvements
More information
• ADO.NET team blog: http://blogs.msdn.com/adonet/default.aspx
• MSDN: http://msdn.microsoft.com/en-us/library/bb399572.aspx
• 10-4: http://channel9.msdn.com/shows/10-4/