LINQ在数据访问层的角色

全文翻译如下：

读了关于LINQ的这篇帖子之后， 我想有一小部分人遗漏了关于LINQ的这一点：LINQ*取代*了任何现有的“数据访问层”。

在编写数据访问层的方法时，诸如GetCustomersByCity，事实上你在数据和业务层之间建立了一个古怪的分隔。在一定程度上，你这是在数据层定义业务逻辑。需要记住的重要的东西是，你的业务层依赖于（RELIES）数据层以获取和持久实体，这样业务层才能处理它们。

LINQ的未来

我想未来LINQ提高我们现有的数据访问层，并且随之大部分的手写的代码（有些非常特殊的用于数据优化的存储过程）会被废弃。

再往前，项目会直接使用SqlMetal（或相同作用的其他代码生成引擎），将LINQ支持的类型构建在你目前的数据访问层中。然后在你增加新的业务逻辑组件，以及更新现有的业务逻辑代码时，在业务层中使用新的LINQ风格的访问。

随后，你会发现大部分的数据访问处理都会由LINQ执行引擎来做，自己写的代码越来越少。

性能

当然，总是会有需要写一些特殊的方法以得到最快速的效果……那些特殊的实例可能会更好，不过坦白来说，引用ScottGu关于LINQ的帖子：“LINQ is fast…very fast”。

原文：

LINQ's role in the Data Access layer.

After reading this post about LINQ, I think a few people are missing the point of LINQ... LINQ *replaces* any "Data Access layers" that have been created. 

When you build methods in your data access layer, like "GetCustomersByCity," you're actually creating a wierd separation between the data and business layers.  In a sense, you're defining business logic in your data layer.  The important thing to remember, is that your business layer RELIES on the data layer to retrieve and persist entities so the business layer can process them.

LINQ's future

I see the future where LINQ augments our current Data Access layers and eventually most of the hand written code (call into very specificly created stored procedures for data optimization) will become obsolete.

Moving forward, a project would simply use SqlMetal (or any other code-gen engine for that matter) and build the Linq-supporting types into your current Data Access layer.  Then, when you add new business logic components, and upgrade existing business logic code, add the newer LINQ-style access into the business layer. 

Eventually, you'll find that most of the data access handling will be through the LINQ-execution engine, and less and less custom developed code.  

Performance

Of course, there's always a case where a specific method is written to short-circuit some code path for maximum speed... Those particular instances may be better, but frankly, to quote ScottGu's post on LINQ: "LINQ is fast... very fast"

Feedback

# re: LINQ's role in the Data Access layer.

Totally agree!!! LINQ with it's provider and mapping models can abstract any data source. 8/1/2007 12:41 PM | Sujit D'Mello

# re: LINQ's role in the Data Access layer.

No, that's not the point of Linq
You want a clear seperation between persistence and business. If you don't have a "data access layer" then you're calling Linq directly from your business code - and aside from the coupling issues, you're forcing yourself into way too much code replication. 1/8/2008 2:59 PM | Adam

# re: LINQ's role in the Data Access layer.

Totally agree with the above comment. The Business Layer should not be aware of the underlaying layer. You should be able to Access a DAO and receive a list of objects and not care about what method has been implemented in getting those Objects.
Look at Microsoft StockTrader.Net and see how you would implement a LINQ version of their DAL. 5/12/2008 5:53 AM | Ed

# LINQ's role in the Data Access layer.

It completely agree! 3/28/2009 4:13 PM | Bolkunov

# Любопытно

Спасибо вам огромное за информацию, почитал с интересом
6/21/2009 5:55 AM | BaLaM

# Прикольно

Согласен в принципе :) Для меня это как раз очень актуально :)
7/9/2009 12:25 AM | Кирилл

# Интересно

Конечно, на самом деле так оно и есть. :)

LINQ's role in the Data Access layer.