A few months ago I finally trusted my first ORM with a production application. <sarcasm>I'd been silly for far too long in turning down the prospect of giving up control over when and how my database calls were executed in order to save months of development time and to more fully realize the promise of object oriented development.</sarcasm>
When it comes down to it the most important thing that matters for an application is how well it is received by the user community. One of the most endearing things a programmer can do for his/her users is to write blazingly fast code. Unfortunately, the fastest code is often not the prettiest, nor is it usually the most elegant and maintainable. Speed and control had prevented me from drinking the Kool-Aid, but they eventually got to me...
LINQ to SQL is a fantastic product in nearly eliminating the need to write code like this:
using (SqlConnection cn = new SqlConnection(cnStr)) {
SqlCommand cmd = new SqlCommand("spGetX", cn);
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add(new SqlParameter("@param1", param1));
List<customobject> results = new List<customobject>();
using (SqlDataReader dr = cmd.ExecuteReader()) {
while (dr.Read()) {
results.Add(new CustomObject() {
Prop1 = db.Field1,
Prop2 = db.Field2
});
}
}
return results;
}
Instead, you can say this with a LINQ to SQL data context around:
return (from db in dataContext.spGetX(param1)
select new CustomObject() {
Prop1 = db.Field1,
Prop2 = db.Field2
}).ToList();
While the number of lines of code you see listed here don't look that different this is just about the simplest example, not to mention that the ADO.net code requires careful, manual editing of strings when database objects change. The code at the bottom requires changes occasionally too but failure to execute them properly results in easy to find and correct compiler errors.
The LINQ to SQL methodology is simple too - just drag and drop database objects from your Microsoft SQL Server (yes, SQL Server only unfortunately) to your .dbml file designer in Visual Studio. Both your mappings and object definitions based on those mappings are completely generated for you when you click the Save button! The simplicity is a triumph and, I have to admit, it must have saved several days of development time on that first LINQ to SQL production project . It's just so much faster to deal with your data when your access to it isn't hindered by manual field definitions and related object definitions.
I've heard the speed of LINQ to SQL vs. direct stored procedure calls is around a 7% hit which I consider to be acceptable. You can always drop back to using ADO.net directly and stored procedures in heavy traffic areas of your app, but neither you nor your users will likely ever notice a difference. You and your users will enjoy the faster turnaround for database design changes though...
As with many good ideas from Microsoft, the future for LINQ to SQL has been discarded in favor of investment in their ambitious Entity Framework attempts. Working with EF 1.0 was a real turnoff and I don't plan on revisiting that mess if I have a choice. LINQ to SQL has a following so I don't imagine Microsoft will kill it or cut support for it in the coming 2 or 3 years but if you decide to use it on a project starting now you'll want to check on the official chatter before investing loads of time...
Tags: