Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Linq2Sql, my thoughts after a few hours of learning

Today I started to play/learn the basics on Linq2SQL and I have to say, it is pretty cool.  However, within the first 20 minutes I came to a cross roads, I was stuck.  I am torn between the 2 different ways to connect to, and query from, a data source.  I don't know which I like better. 

Below are the 2 different ways to connect, as well as my opinions as to the pros/cons on each one.  Please take into account I have NO real world experience using Linq, these are just my thoughts on the subject

Approach 1
The most common way I have seen to use Linq2SQL is to generate a custom DataContext class (.dbml class) via the IDE.  This will generate all your DTO classes for you as well as the mappings between tables/objects.

  • Pros
    • Creates the DTO classes that map directly to your database tables for you.  This can save you a bit of time versus creating the DTO's buy hand.
    • When the DB schema changes, you simply have to refresh the IDE and all the changes are brought down
    • No need to sprinkle your DTO's with attributes to allows Linq to use them. (ie [Table(Name="Sport")]
  • Cons
    • The generated code creates a lot of overhead.  For example, the default set code will raise 4 events as well as set the new value.  If you are using these events, great, but if not you have wasted cycles.
    • Gives you less control over your DTO objects
    • Would NOT work well if you are trying to back in Linq2Sql into an existing application

Approach 2
The second way is to create a standard DataContext and create the mappings on the fly.  This way does NOT generate your DTO's you

  • Pros
    • You can use your existing DTO's (assuming you have some)
    • You have 100% control over how your DTO's are created/generated
    • No events are fired when you set properties, unlike the generated DTO's.  This is assuming you don't WANT the events.
    • Would work well in the scenario where you are trying to back Linq2Sql into an existing application.
    • Because you have to hand wire the DTO's to the db tables, you become more aware of what is going one and are more able to fix 'odd' issues as the appear.
  • Cons
    • You need to sprinkle your existing DTO's with various attributes to all them to be mapped to you database tables.
    • When your DB schema changes, you need to update your DTO's by hand to reflect the changes.
    • You need to use the db.GetTable<EntityHere>() (db here is a DataContext instance) in order for the context to know about a given table.

Ok so there you have it, both ways to connect to the db using Linq along with my thoughts on pros/cons.  At the end of the day, I think I like the idea of Approach 2 because I like to have more control over what my code does, although I have to admit I like the auto generation capabilities of Approach 1.  I wonder if my attitude with respect to which approach to use will change over time, who knows:)

Till next time,


Posted 03-13-2008 1:59 PM by Derik Whittaker
Filed under: ,

[Advertisement]

Comments

Peter Ritchie wrote re: Linq2Sql, my thoughts after a few hours of learning
on 03-13-2008 4:33 PM

In approach 1, it's actually two events, not four.  OnXXXChanging and OnXXXChanged are partial methods.  If you don't extend the LINQ to SQL class and implement those partial methods the method calls aren't emitted into the IL stream.  This leaves only the two events PropertyChanging and PropertyChanged.

Derik Whittaker wrote re: Linq2Sql, my thoughts after a few hours of learning
on 03-13-2008 4:39 PM

@Peter,

You are correct.  Sorry about that.

El Guapo wrote re: Linq2Sql, my thoughts after a few hours of learning
on 03-13-2008 9:36 PM

"When the DB schema changes, you simply have to refresh the IDE and all the changes are brought down"

Are you sure? In my experience there is no way to refresh the schema. You have to delete and re-import. If there were a way to do it, I would love to know !

Derik Whittaker wrote re: Linq2Sql, my thoughts after a few hours of learning
on 03-13-2008 9:51 PM

@El Guapo,

Sorry for the confusion.  I should have not simply stated you can refresh.  You DO have to delete the table and re-add.

BTW, if anyone on the Linq team is watching, a refresh feature would be nice.

Derik Whittaker wrote Playing with Linq2Sql and various performance tests
on 03-14-2008 10:08 AM

In my last post ( here ) I raised the question as to how to create the DTO/DataContext to be used when

Kristofer wrote re: Linq2Sql, my thoughts after a few hours of learning
on 09-08-2008 2:24 AM

@El Guapo && @Derik:

I have written an add-in that adds the missing "refresh" feature to the L2S designer. You can download it from www.huagati.com/dbmltools if you want to try it out.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)