News

VSLive! San Francisco Preview: LINQ to SQL Q&A with Perry Birch

• By Becky Nagel
• March 4, 2008

There's a lot that LINQ to SQL (formerly called Dlinq) can offer developers, and in this Q&A preview of his session, Birch outlines what's new, shares some of his favorite LINQ to SQL features and more.

What do you think are the top benefits for using LINQ to SQL?

BIRCH: There are two primary benefits that I enjoy when using LINQ to SQL, the first one being the ease of transition for people moving from standard T-SQL query syntax to this new method of data retrieval. Both LINQ to SQL and T-SQL have very similar syntax and command results. It is also easy to create the mapping files that are used.

The second benefit is that LINQ to SQL derives from LINQ, which means that the techniques and syntax used to query for data becomes very similar in nature to querying for objects, XML and any other LINQ-enabled data source.

What's your favorite LINQ to SQL feature/tool?

B: It really depends on the type of project I'm working on. For small and prototype projects, I really love the domain-specific language designer and code generation found in SQL Metal, simply because it is a pretty trick. However, when I'm looking at building a bigger, tiered application, I tend to shy away from all the attribute markup that is engrained into the class definitions; then, my second favorite feature (and the real reason to use LINQ to SQL) is the T-SQL generation. For anyone who is a db mapping enthusiast like me and hasn't yet looked into these, I highly recommend digging into the Binary Execution Trees which "LINQ to N" engines use to map to the various data stores.

When you first started using LINQ to SQL, was there anything that surprised you?

B: I would say the biggest "hmm..." moments for me were related to disconnecting and reconnecting objects to the Data Context. I typically try to wrap the data calls into one or more interface contract(s) and pipe the data to the caller using serialized data via services. The problem is in the deserialization and reconnection of the object to the Data Context for create and update operations. I'll be using one workaround in my presentation at VSLive! 2008 at the end of March so I don't want to give too much away...Seriously, though, there are a few valid approaches to getting around this issue depending on your requirements/code style that are pretty easy to find if you search for them.

For users of LINQ to SQL's predecessor ObjectSpaces, what are the biggest differences that they should be aware of?

B: The best way to clarify the differences between Object Spaces and LINQ to SQL is by showing the code. For example, to add a given object to an object spaces mapper you would use syntax like the following:

public void addAnimal(int ID, string Species, string Age, string Weight)
{
   Animal animal = null;
   IObjectSpace objectSpace;
   objectSpace = ObjectSpaceFactory.CreateObjectSpace(mapFile);
   animal = (Animal) objectSpace.CreateObject(typeof(Animal), ID, Age,
Weight);
   objectSpace.Update(animal);
}

There are a couple key elements to point out with this syntax. First, notice that the result type is not explicitly cast and requires a (Animal) boxing operation and a typeof(Animal) to specify the expected return type. Second, notice the list of parameters being passed into the create call.

An example of similar functionality using LINQ to SQL looks something like this:

// This is now just a helper method
public void addAnimal(string Species, string Age, string Weight)
{
   Animal animal = new Animal();
   animal.Species = Species;
   animal.Age = Age;
   animal.Weight = Weight;
    // Call to the actual add method
   addAnimal(animal);
}

public void addAnimal(Animal animal)
{
   ZooDataContext dc = new ZooDataContext();
   dc.Animals.Add(animal);
   dc.SubmitChanges();
}

It looks like more code but the rest of the app would be using the Animal POCO (plain ol' CLR objects), so most calls would now be using objects and one could simply use the new object instantiation method to create the object and forego the helper method entirely:

Animal animal = new Animal { Species = "Feline", Age = 5, Weight = 100 };
addAnimal(animal);

Another and even more critical distinction comes when querying for objects. In ObjectSpaces the query filter has to be provided to the engine. This requires strict convention adherence and/or domain knowledge in order to create the queries. You may see something akin to the following:

string findFilter = "ID="+ID;
animal = (Animal)objectSpace.GetObject(typeof(Animal), findFilter);

The developer writing this code has to know that the key field in the DB is named ID and any, more complicated filters require even more pre-knowlege of the database schema. In LINQ you would be using intellisense and type safe criteria to specify the filter:

var animal = dc.Animals.Single(a => a.ID == ID).SingleOrDefault();

Coming from a heavy SQL background and having created many cross-domain filtering methods, I really appreciate the flexibility, safety and simplicity of the new syntax.

Do you have a favorite LINQ to SQL tip you could share with our readers?

B: The only thing I can really say is to jump in and start playing with this stuff. If you want a quick "up to speed" kind of experience, a good friend of mine, Daniel Egan, recently recorded a presentation where he goes into some pretty good depth on all the stuff behind LINQ to SQL and even shows some good intro code off. The link to that presentation can be found here.

What, if any, downsides do you feel LINQ to SQL has?

B: Right now, the two biggest downsides to LINQ to SQL is the lack of support for complex type mapping which, in most cases, precludes it from being very useful for legacy databases. Also, the current implementation of LINQ to SQL is, as the name implies, limited to mapping to a SQL Server Database, which means that all of the Oracle guys out there are missing out. The upside is that the LINQ semantics allow the creation of LINQ to Oracle.

Besides LINQ to SQL, what else in LINQ would you encourage developers to learn more about right away?

B: The first step is to jump in and start playing with the new language features. Besides saving a lot of typing, when used properly, they can help you to more clearly express your code's intent.

If you haven't done so already, start using more delegates and play around with the anonymous methods. Once you have those two concepts down, you can start refactoring your code down to lambda expressions, then things start getting really exciting (and confusing for awhile; don't get intimidated).

A habit I picked up when writing lambdas is thinking to myself as I write out the expression. For example:

var myList = new List<ComplexObject>(); <-- anonymous type!

... Populate the list with a bunch of values ...

var average = myList.Average(c => c.IntegerProperty);

While writing the "c => c.IntegerProperty" I'm thinking something along the lines of:

"c is a ComplexObject and I want the IntegerProperty"

or

"c such that I get the average of all ComplexType's IntegerProperty"

Our thanks to Perry for this interview! For more on LINQ to SQL, be sure to attend Perry's session at VSLive! San Francisco, March 30 through April 3 at the Moscone Center.