Sunday, June 22, 2008

LINQ to SQL frustration

I've been experimenting quite a bit with LINQ to SQL, in combination with the Microsoft Sync Framework for ADO.NET. This places a limitation of SQL CE 3.5 SP1 on the client side, so no stored procs and a sub-set of field types only.

GUID as Primary Key

One thing I noticed is that you can't set a SQL CE table to use a GUID as the Primary Key using NewID() for the default. Sure SQL CE will let you do it, but LINQ to SQL has a fit when you try and insert a row, apparently you're not allowed to mark a 'uniqueidentifier' column as auto-generated... perhaps that's some hangover from the Beta or something, since Sync has some issues too (if you sync a server-side table to a local table it loses the default and loses the "is row guid" property, requiring you to intercept the schema creation to turn those features back on).

This is no big deal I guess, since if you are using SQL CE then your app is all that's going to be changing rows, so you can simply add a partial class that sets the GUID column to Guid.NewGuid() in the OnCreated() partial method.

No Designer Support for SQL CE

While you can use SQLMetal.exe to create your mapping, it's not the same experience. Then again, given the nature of my focus here it's probably a better idea since I want to adjust my schema often based on my ever-changing sync requirements.

It's Not a First Class OR/M

This one might get me some hate mail, but I feel that it's a pretty poor OR/M experience. For production code I would suggest NHibernate as it allows for the vast differences between your Domain Model and your Data Model.

While LINQ to SQL has some support for inheritance it's still a baby in the OR/M world. Any project beyond 5 tables in size would probably have to be adjusted to fit the technology instead of having the technology make the project easier.

Summary

From my experience so far, I think that LINQ to SQL is great for doing a demo, great for small projects and perhaps some web apps, but can't be taken seriously in the enterprise application development area.

Still, that wont stop me from using it as a replaceable data persistance layer for demo apps and in articles I plan to write.

No comments: