ADO.

NET Entity
Framework & Your Data
Access Layer
Wade Wegner
Architect Evangelist
Microsoft Corporation
wade.wegner@microsoft.com
http://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

Its a tool
CRUD
Query model
Mapping

Entity Framework
What does it do?
Persistence
Querying
Manages transactions
Manages concurrency

Its a tool
CRUD
Query model
Mapping

The Entity Framework is an

O/RM

The ultimate question

Where does this go?
User Presentation

var apartments =
from a in db.Apartments
where a.State == IL
select a;

Business Logic
Data Access Logic

Data Sources

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
(DTOs)
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
var bo = new CategoryBusiness();
bo.Load();
this.categoryGridView.DataSource =
bo.ActiveCategories;

Forms

UI Presentation

var db = new AdventureWorksEntities();

var activeCategories =
from category in
db.ProductCategory
where category.Inactive != true
orderby category.Name
select category;

Business
Objects

Business

Data Access
CS

MSL
MSL

SS

ADO.NET
Entity
Client

ADO.NET
Object
Services

Entities

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)
Cant easily switch ORM
Data validation support is limited.

Validation & Business Logic

public 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 last

DAL 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/defaul
t.aspx
MSDN:
http://msdn.microsoft.com/en-us/lib
rary/bb399572.aspx
10-4:
http://channel9.msdn.com/shows/104/