DEVELOPING APPLICATIONS WITH LINQ 2 SQL

Sidar Okhttp://www.sidarok.com

Agenda• Common Glossary• Problem• Building in house ORM/DAL vs Use

an existing one• Linq to SQL Comes into play : Myths

and Realities• Linq to SQL beyond drag and drop :

Concepts

Agenda (cont’d)

• Linq to SQL Entity Model• Mapping Engine– Attribute Level or External ?

• SQL Metal to rescue– What it does, what it lacks

• Understanding DataContext• Change Management & Change

Communication Strategies

Agenda (Advanced)

• Debugging and Troubleshooting• Transaction Handling• Concurrency & Conflict Handling

Scenarios• Entity Validation• Security Model• Serialization• Performance Advices & Best

practices

Common Glossary

• ORM (Object Relational Mapper)• Lazy (Deferred) Loading • Eager Loading• Unit of Work Pattern– Object (Dirty) Tracking

• Repository Pattern• Law of Leaky Abstractions• Plain Old CLR Objects (POCO)• Persistence Ignorance• TPH Model mapping• DTO (Data Transfer Objects)

Problem

• Advanced programming in relational system = Pain of Hell redefined on earth

• Impedance Mismatch• Re-Inventing the Flat Tire ? Over and Over ?– Basic CRUD ?

• Reacting to changes, maintainability

Solutions

• Putting Everything in DB• Utilizing Custom Code Generation • Using an Object Database• Using a ready to go ORM – Linq to SQL– Entity Framework– Nhibernate (Open Source)– LLBLgen

Advises on Building Custom DAL/ORM

DON’TTransactio

ns

Paging

Dep

end

ency O

rder

Multi-Threading

Cas

cad

ing

CR

UD

Concurrency

Caching

Identity

Management

Subquerying

Lazy Loading

Debuggin

g Aggregation

Configurability

Linq to SQL into the pitch

• Microsoft’s Full Linq provider for MS SQL• Built on top of ADO.NET– Previously owned by C#, now ADO.NET

• A designer and a RAD environment• Plays well with System.Transactions• Supports TPH model• Supports custom queries & stored procedures

Myths & Realities

• L2S is for less advanced users • L2S is slow • L2S saves me building DAL • L2S just supports SQL 2005– 2000, 2005, 2008 & CE

• L2S doesn’t have an N-Tier story• You have to have a db schema first• You have to have attributes

Limitations and Drawbacks

• L2S doesn’t support : – Other DB vendors (Oracle, MySql etc)• FYI There is a DBLinq project -http://code2code.net/DB_Linq/

– Multi table mapping– Many to Many associations

• Designer experience isn’t the best• Batched queries not supported OOTB• Work disconnected, track yourself

Beyond Drag & Drop: L2S Concepts

• Object Tracking• Deferred Loading– Load Options

• Optimistic Concurrency– Change Conflicts

• Change Sets

L2S Default Entity Model

• Entity Classes are partial– Drawback: Extension only in same assembly

• Entities implement “INotifyPropertyChanging”, “INotifyPropertyChanged” interfaces

• (1-1) -> EntityRef<T> , – (1 - *) -> EntitySet<T>

• Bunch of partial Methods (OnLoaded, OnCreated etc.)

Mapping Engine

• System.Data.Linq.Mapping namespace• Mapping Engines Built in– Attribute Based (Internal Mapping)– Xml Based (External Mapping)

• L2S Designer doesn’t support XML Based– But SQL Metal tool does

Demo

Domain First Development with

XML Mapping&

POCOs

Sql Metal – Can and Can’ts

• CAN Generate Entities– Option of Pluralizing Names– Option of giving them a base class

• CAN Generate DBML • CAN Select from VB or C#• CAN’T Partially Generate• CAN’T Use on a Recursive SP • There are alternatives– T4 Generation by Damien Guard (www.damieng.com)

Understanding DataContext

• A DataContext is a Unit of Work (UoW)• Multiple DataContexts can share connections• Work Modes– Connected & Disconnected

• .SubmitChanges– Transactional – Overload with Conflict Mode

• DataContext is the boss

DataContext is da boss

• Connected Mode– Life is easy– Throw an retrieve everything to/from DC– Object Tracking is a joy– Not very likely to happen

• Disconnected Mode– Attach untracked objects for Update & Delete– Object Tracking doesn’t work

Change Tracking Strategies

• Track changes in UI – UI Box knows what it changed• Pros

– EntityBase, easy to implement– Hitting DB only once

• Cons– UI has to keep track– Keeping track & retrieving status from association trees can be

daunting– Sending whole tree back is proven to be chatty

Sequence Diagram

Change Tracking Strategies (cont’d)

• Retrieving Entity Tree from DB– Hitting the DB to get original version and compare• Pros

– UI doesn’t need state management– DAL doesn’t care about any state, no implied contracts

• Cons– Hitting DB twice to retrieve – Needs a robust concurrency & error handling scenario– Still sending whole tree, chatty

Change Tracking Strategies(cont’d)

• Designing change DTOs– Sending only change sets as DTO s• Pros

– Decreases the communication cost in both ways– Encourages use of DTO s

• Cons– Still change tracking on the client boxes– Not trivial to implement– Mappings from/to DTO can be drudge

Change Tracking Strategies(cont’d)

• Designing change DTOs– Sending only change sets as DTO s• Pros

– Decreases the communication cost in both ways– Encourages use of DTO s

• Cons– Still change tracking on the client boxes– Not trivial to implement– Mappings from/to DTO can be drudge

Demo

Developing Applications In

Disconnected Mode(aka Multi Tier Fairy Tale)

Sum up

• Writing a custom ORM usually means reinventing the wheel

• Linq to SQL is a relatively powerful ORM• It is an abstraction over SQL Server• DataContext is at the center of all,

implementing UoW pattern• One can plug own mapping source• Supports POCOs natively• Only supports TPH Model

Advanced Topics

• Debugging and Troubleshooting• Transaction Handling• Concurrency & Conflict Handling Scenarios• Entity Validation• Security Model• Serialization• Performance Advices & Best practices

Thanks for listening !

• Questions ?

– http://www.sidarok.com – http://cork.mtug.ie