MOVING FROM LINQ TO SQL TO EF

Jim Wooley

AGENDA

Why migrate?

Entity Shapes

Query differences

Context considerations

Demo migration

MIGRATION IMPLICATIONS

Migration not required

If it ain’t broke, why fix it?

Because it’s cool != cost justification

Why Migrate?

Increase maintainability

Reduce complexity

Add functionality

Incremental migration encouraged

Use it in new components

Have tests to ensure refactoring

ENTITY SHAPES

ENTITY MAPPING LAYERS

Physical

Logical

SSDL

Mapping

MSL

Conceptual

CSDL

Author

Publisher

Author

Address

Publisher

Author

Entity

Publisher

Entity

User

MANY-TO-MANY

INHERITANCE – TABLE PER HEIRARCHY

INHERITANCE-TABLE PER TYPE

INHERITANCE-TABLE PER CLASS

POCO CONSIDERATIONS

L2S EF

Collections inherit from

Table<T>

POCO Entities Supported

through XML Mapping

Collections from ObjectQuery<T>

POCO Entities Inherit from EntityObject or ComplexObject

IPOCO Support

Coming with V4

Post 4.0: Code First/Code Only

MAPPING OPTIONS

LINQ to SQL

EF

Migrating an Application

DEMO – GETTING IT TO COMPILE

QUERY GENERATION

Dim q1 = From cust In nwd.Customers _

Where cust.Country.StartsWith(“U")

LINQ to SQL:WHERE Country LIKE @P0; @P0=“U%”

EF 1.0:

Where(CAST(CHARINDEX(N’U%’, Country) AS int)) = 1

EF 4.0:WHERE Extent1.Country LIKE N’U%’

QUERY DIFFERENCES

L2S EF

Use Contains to create IN

clause

Projecting to Structure

First/Single

No support for IN. Use

multiple OR clauses in

WHERE statement.

(Fixed in 4.0)

DYNAMIC QUERIES

LINQ TO SQL EF

Use deferred execution and

query compositionality

Dynamically build

Expression Trees

IQueryable extended to

take strings as predicates

Use Entity SQL

STORED PROCEDURES TO SELECT

LINQ TO SQL ENTITY FRAMEWORK

Select as Function

Ctx.ExecuteCommand for

POCO results

Ctx.IMultipleResults

Scalar results

ExecuteCommand

Select as Function

No support for POCO

No support for Multiple

Results (see EFExtensions)

Build extension method for

scalar results

Extension method using

ExecuteNonQuery

STORED PROCEDURES TO UPDATE

LINQ TO SQL EF

Use designer to map

any/all stored procs

Infers usage based on the

InsertT, UpdateT, DeleteT

functions

Must map all 3 portions of

CUD operation

DYNAMIC UPDATES

L2S EF

Ctx.P.InsertOnSubmit

Ctx.P.DeleteOnSubmit

Child – Add/Remove

InsertAllOnSubmit

Ctx.AddObject

Ctx.DeleteObject

Ctx.AddToT,

Ctx.DeleteFromT

Child – Add/Remove

CONTEXT CONSIDERATIONS

Options

Concurrency

Transactions

Exceptions

Logging

EAGER LOADING

LINQ TO SQL EF

DataLoadOptions

For grandchildren: include

multiple LoadWith

Can’t change options once

set on context

Can add filtering

Parent.Include(“Child”)

Parent.Include(“Child.GC”)

Options set per query

Filter in query

DEFERRED (LAZY) LOADING

LINQ TO SQL EF

Enabled as long as the

context remains in scope

DeferredLoadingEnabled

Explicitly call Child.Load

CodeGallery sample for

Lazy Loading.

Lazy Loading by default in

4.0

Migrating an Application

DEMO – FIXING THE BUGS

IMPORTANT POINTS

Migration isn’t required

Be prepared to justify cost

Have regression baselines before refactoring

Good architecture begets easier migrations

Benchmark and check performance

Check generated queries

RESOURCES

http://blogs.msdn.com/adonet/

http://blogs.msdn.com/efdesign/

EF Migration whitepaper:http://msdn.microsoft.com/en-us/library/cc716791.aspx

Forums: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/threads/

http://learnentityframework.com

Jim Wooley

www.ThinqLinq.com

www.LinqInAction.net

www.Twitter.com/LinqKinq

QUESTIONS