LINQ is a new addition in C# 3.0. The technology allows for a language-integrated query mechanism, hence LINQ. Which essentially means you can query a data store using built-in language features. No longer is it necessary to write elementary SQL statements to access your database. With LINQ to SQL, you can create an object-relational mapping using the designer built in to Visual Studio 2008. The end result is a set of classes that map to tables represented in your database. The DataContext is the other main pillar to LINQ. Its purpose is to facilitate the communication between the entity classes generated by the O/R designer and your physical database.

I’ve been toying around with LINQ and thought it would be a useful technology for me in the future. It removes the need to build out all of the fundamental SQL queries for data bound objects. That alone makes it a worthwhile topic to read up on. What I noticed while cruising around the web is that every example on LINQ is very simplistic and not representative of a real world scenario. I’m sure it’s because the focus is on LINQ and nothing else, but eventually you need to see how it fits into a real enterprise class system.

With planning underway in a new project, I thought it was the perfect time to investigate LINQ further. I just finished up a small project where I used LINQ in a minor and trivial way. It was about as complex as the examples you see online. But now I needed to design an architecture in the more traditional n-tier sense, something that would meet the needs of a complex web application.

Using the traditional layers, I drafted up my architecture and tried to find LINQ’s place. Remembering the entities and DataContext generated by the O/R designer, it was easy to see that the entities generated fit in what I call the Entity Layer. These skeleton objects simply represent database tables and are used by the business and data layers. Think of them as transitional objects between the various layers. The DataContext stood out though. It’s data-centric nature dictates that it should exist in the data layer, not the entity layer. However, since these two classes of objects are generated by the O/R designer, I can’t easily separate them without redoing it each time the model is generated. We’re essentially collapsing the entity and data layers, or at the very least, letting the DataContext slip under the radar. But remember, all of the data access in LINQ is using that DataContext class. So your data layer may be forming the LINQ queries but the entity layer ends up executing them since the DataContext lives there. Not exactly the separation of concerns I was architecting.

I’ve yet to find an elegant solution for this problem. I’m very happy with the architecture I have minus this one key element. If anyone out there has been in this situation before, of trying to find a solid design that includes LINQ, please post and give me your thoughts. I’ll be sure to post my solution once I come up with something worthwhile.