Musings of Geekdom by Eric Newton

tail /var/log/thoughts
posts - 88 , comments - 41 , trackbacks - 68

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.  


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"

Some other articles about performance with LINQ:


More to come...

Print | posted on Wednesday, July 18, 2007 9:42 AM |



# 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
Comments have been closed on this topic.

Powered by: