Musings of Geekdom by Eric Newton

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

Wednesday, July 18, 2007

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...

Posted On Wednesday, July 18, 2007 9:42 AM | Comments (3) |

ScottGu and LINQ in VS "Orcas" B2

ScottGu has been busy writing some articles about some of the new features contained in the new Beta 2 bits of Visual Studio "Orcas":

- Part 1: Introduction to LINQ to SQL
- Part 2: Defining our Data Model Classes
- Part 3: Querying our Database
- Part 4: Updating our Database
- Part 5: Binding UI using the ASP:LinqDataSource control

So far, its an interesting read... In particular I like the idea of the <asp:LinqDataSource> control, but I'm not so sure the implementation was correct... 

At first glance, having a "TableName" property for the control seems counter-intuitive to LINQ, since I question how many times would I only use 1 table...?

However, I'd like to reserve judgement until we get our hands on it and can check out the LinqDataSource control for ourselves.

In the mean time, we all have a lot of cool stuff to look forward to!

Posted On Wednesday, July 18, 2007 9:42 AM | Comments (0) |

Powered by: