It is really interesting to see what LINQ will bring to the developer community. I personally think that LINQ is the feature in VS2008 that brings real developer productivity. Many language enhancements make the language just more complex, but LINQ is the one that makes it simpler. Increased developer productivity is definitely something we (the software industry) can use. We should ask ourselves the question has our productivity really improved in the last 15 years? Personally I don’t think so. This is off course very bad for the image of the industry. LINQ seems to be a very promising technology to increase developer productivity. At least for the data access part of our applications.
When you start using LINQ it becomes very soon clear that LINQ is much more than only a data access technology. For example each “foreach” statement is a candidate to be replaced by a LINQ query. But the main part of LINQ is focused at data access (at least for me). LINQ has to do with data connections, OR/M, queries and data manipulation. Typically data access layer functionality. Although the technology is interesting the impact of LINQ at the architecture of our applications is of much more interest to me. It really surprises me that most articles and blog posts are about the technology while the design and architecture of an application is also very interesting. (I really like the series of articles Scott Guthrie has written)
After programming LINQ for a while the main question which comes into my mind is: “Is LINQ to SQL the Data Access Layer (DAL)?”. At the moment I really think the answer to this question is “yes”. I think that LINQ will change the design of many .NET applications in the near future. We finally will remove a layer!
What is a DAL?
Great question. When you google for a data access layer definition you will find many different statements en opinions. At Wikipedia you will find some description. Some general points (a.k.a tenetsJ) can be filtered by all the definitions:
- Responsibility for data access (querying & data manipulation)
- Abstraction of underlying data store (e.g. SQL Server)
- Mapping between OO and relation information
- Provides services
In my opinion the data access layer has indeed something to do with all four points listed above. In .NET this will be translated in a few assemblies which are referenced by the business layer.
What has LINQ to do with a DAL?
LINQ to SQL is about data access with a SQL Server. LINQ to SQL provides a model for the OR/Mapping and a data context. Using LINQ to SQL provides you with an easy programming model to access and manipulate data. These are important aspects you have to build in your DAL. So, LINQ is a great technology to use inside your DAL. You design and program the abstraction (classes, interfaces & methods) and provide the services (WCF) the rest is LINQ code.
I really think that I will see many solutions were LINQ indeed is used as described above. This will end up with “empty” methods which are nothing more than a wrapper around a LINQ statement. Something likes this:
public static class DataHelper
{
public static IQueryable
{
DinnerNowDataContext context = new DinnerNowDataContext();
return from r in context.Restaurant
select r;
}
}
Will this type of code really improve our designs? More important, will this type of code really improve the developer productivity? I don’t think so…
Another problem has to do with the LINQ language integration. You can use LINQ very usefully in your business and presentation layer as well. Even when you use a method as above you can still write a LINQ query in the business layer on top of the GetAllRestaurant() method. Is this correct from a architecture point of view? Why not, LINQ is just a great language feature which you use everywhere. But if that is the case, where do you write queries? In the data access layer? Or in the business layer? Or even in the presentation layer? This gives the developer many choices, and choices are bad for productivity!
Is there a better way to use LINQ in our design?
Yes, I do think so. If we start from the point of view that LINQ to SQL is our data access layer. We just build a data context and map our tables to classes with the standard VS2008 functionality. We configure our data store connection by using a configuration file and we are done. You have your data access layer. We simple do not discuss what goes in which layer, that will save a lot of time.
We allow our developers to use LINQ queries all over the place. It is just a language feature that improves the productivity and provides us with more readable code.
That’s it. I think LINQ to SQL is a great DAL (or whatever you wane call it). It is a mind shift. Stop programming useless classes. Start thinking about better software and a better productivity!
