ADO.NET Entity Framework & Your Data Access Layer

Wade WegnerArchitect EvangelistMicrosoft Corporationwade.wegner@microsoft.comhttp://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/