OdeToCode IC Logo

Two LINQ to SQL Myths

Monday, May 12, 2008

LINQ to SQL requires you to start with a database schema.

Not true – you can start with code and create mappings later. In fact, you can write plain-old CLR object like this:

class Movie
public int ID { get; set; }
public string Title { get; set; }
public DateTime ReleaseDate { get; set; }

… and later either create a mapping file (full of XML like <Table> and <Column>), or decorate the class with mapping attributes (like [Table] and [Column]). You can even use the mapping to create a fresh database schema via the CreateDatabase method of the DataContext class.

LINQ to SQL requires your classes to implement INotifyPropertyChanged and use EntitySet<T> for any associated collections.

Not true, although foregoing either does come with a price. INotifyPropertyChanged allows LINQ to SQL to track changes on your objects. If you don't implement this interface LINQ to SQL can still discover changes for update scenarios, but will take snapshots of all objects, which isn't free. Likewise, EntitySet provides deferred loading and association management for one-to-one and one-to-many relationships between entities. You can build this yourself, but with EntitySet being built on top of IList<T>, you'll probably be recreating the same wheel. There is nothing about EntitySet<T> that ties the class to LINQ to SQL (other than living inside the System.Data.Linq namespace).

LINQ to SQL has limitations and it's a v1 product, but don't think of LINQ to SQL as strictly a drag and drop technology.

Chad Myers Sunday, May 18, 2008
Are there any links with examples of people doing domain-driven design/persistence ignorance style persistence stuff with Linq2Sql?

I know Ian over at CodeBetter did some stuff like this and I haven't made it through his whole series, but it didn't impress me as something that would replace NHibernate as it was lacking several critical features.

Almost all the examples/samples I've seen of Linq2Sql are of the drag-n-drop-your-database-into-your-code ilk.
scott Monday, May 19, 2008
@Chad: I don't know anyone other than Ian who has graciously taken the time to write about DDD with L2S.

nHibernate is years ahead of L2S. The one advantage L2S has is its exteme simplicity (and not the drag and drop designer type). That's also one of it's big weaknesses - only basic mappings are available, only SQL Server is supported. If that's all you need its refreshingly light, and the standard LINQ operators make it easy to build repositories.
Jim Wooley Wednesday, May 28, 2008
Scott, I fully agree with you that LINQ to SQL does offer some benefits over the EF in terms of POCO support. Using the XML mapping is a great solution for existing classes so that you can keep the classes completely isolated to the underlying technology. We discuss this option along with the associated pluses and minues in LINQ in Action. In addition, I will be calling attention to it in my beyond the basics talk at the TechEd Tweener weekend.

The main drawback that LINQ to SQL has in relation to the Entity Framework and NHibernate is the one-to-one table mapping requirement. It doesn't allow for the richer schema mappings without using views and stored procs.
scott Wednesday, May 28, 2008
Jim: Agreed. The mapping is a deal breaker for many scenarios, unfortunately.
Comments are closed.