Anko's Blog - eh? : LINQ to SQL is the Data Access Layer(DAL)
有几句话我很赞成，
1，一些语言特性只会带来复杂性，而LINQ却是让事情变得简单。
2，我也很喜欢LINQ。
3，对于是否在DAL层之上仍然使用LINQ语句来访问DAL层提供的数据集的疑问（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’，而我现在就是这么做的。然后，他提出与kris vandermotten类似的观点：这样就要求大家对于“究竟在那些层次上使用LINQ做出选择”，而对于开发人员和开发效率来说，是一种灾难（This gives the developer many choices, and choices are bad for productivity!）。
4，本文作者对于在使用LINQ之后的DAL的设计的解决方法是，使用DBML文件自动创建了DataContext和Entity Classes之后，这些就是DAL了。不需要在浪费时间讨论问题了！我想者和我现在的想法是一致的。例如在我现在Hillytonbs中涉及的物料管理类库中，获取“当前物料列表”的函数中直接使用DataContext，同时加入了“只获取未禁用物料”的逻辑判断，这一层也就是业务层了，也就是说不存在单独的DAL层了。这和kris vandermotten的文章观点是一致的：And indeed, that means we don’t need/write/use an Entity Access Layer. The business logic directly accesses the one assembly generated by SQLMetal.
LINQ to SQL is the Data Access Layer(DAL)
The last few weeks I have found the time to take a better look at LINQ. I studied the architecture and the technique in more detail. I have a special interest in LINQ to SQL since I love databases, especially Microsoft SQL Server. I have to admit I really like LINQ. The part I liked most is the native language integration in both C# and VB9. For a developer it feels very natural to use LINQ within the code.
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<Restaurant> GetAllRestaurants()
{
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!
Published Thursday, November 01, 2007 4:29 PM by Anko Duizer
Filed under: Architecture, .NET 3.5
Anko's Blog - eh? : LINQ to SQL is the Data Access Layer(DAL)
