Archive for the ‘LINQ’ Category

Use LINQ’s Select and Initializers to Make Mapping Easier

Mapping data between types on a Web Service can be a collosal pain. There are various frameworks out there that can speed things up, but sometimes you just need to do it by hand. Fortunately some of the features introduced with C# 3 can help speed things up.
Say the type on the server looks like [...]


More Fancypants LINQ Fun

Say you had an object model that was generated from a database like so:
public class Lecture {
public List<Speaker_Lecture> Speakers { get; set; }
}

public class Speaker_Lecture {
public Lecture Lecture { get; set; }
public Speaker Speaker { get; set; }
}

public class Speaker {
public string Name { get; set; }
}
Unfortunately, you’re stuck with that semi-ugly Speaker_Lecture model, and [...]


Using LINQ to Reduce Collections

Recently, I had a Dictionary<string, string> object that I wanted to display as a single string, essentially like “[key1] => value1  [key2] => value2” and so on. Back in the olden days of .NET 2.0 and prior, you could have just done it like this:
string s = ""; // Or a StringBuilder
foreach (string key in [...]


LINQ To SQL and Tight Coupling Part 3

Last time, we tweaked our code to make it a little easier to understand and maintain. So that means we get to dirty it up again!  Our current object model has very simple mapping of one table to one class, with no associations between them. In the real world, this doesn’t happen too often (and [...]


LINQ To SQL and Tight Coupling Part 1

Each major release of the .NET framework and Visual Studio has at least one killer feature that makes developers stuck in prior versions pine longingly for it. With .NET 3.5 and Visual Studio 2008, that big one is LINQ. The reason being is that it provides built in OR/M functionality with SQL Server. To put it succinctly: it can take database tables and create .NET classes and the code to bind them to each other.

It’s pretty hot stuff, or it is until you look at your business objects and realize that they are directly tied to your data layer. This is known as “Tight Coupling” and is a Bad Thingtm. It is also not very testable - to test anything having to do with your objects will result in the database being modified.

So does this mean we have to chalk up LINQ to SQL as another neato feature that is pretty but only suitable for marketing demos? Not necessarily; there are ways that you can detach the coupling, but it’s not the easiest thing in the world.