DEVELOPING APPLICATIONS WITH LINQ 2 SQL Sidar Ok

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

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 – 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, – (1 - *) -> EntitySet 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

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 (

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

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 ? – –