Architecture for LINQ to SQL
People are beginning to ask questions about how to architect applications that use LINQ. It is important to remember that LINQ is both a set of language features and a set of additions to the framework.
While there are no best practices for LINQ today, because the technology has not been in use long enough, when we look at some of the LINQ providers, such as LINQ to SQL, we can start to develop our best practices based on the foundations of best practices around existing tools. While it provides new ways of solving some existing problems the patterns that it uses are well understood, even in their C# 3.0 clothing. To draw parallels with existing best practice, to see where it can inform us, we need to understand what roles LINQ plays in our Enterprise Architecture. That way, we can work with LINQ when we use it within our own applications rather than against it.
- What are some of the questions we hope to answer by looking to existing practices?
- What is the relationship between LINQ to SQL (and LINQ to Entities for that matter) and the data access object (DAO) or Data Mapper pattern?
- How do we write dynamic queries with LINQ?
- How do we write an NTier application , when LINQ is part of our mix?
We’ll try to address some of these issues, and others. Along the way we will define what LINQ is, what enterprise architecture looks like, what the difference between tiers and layers is, and how we should write a distributed system.
First we will look at what we mean when we refer to LINQ itself, and then at what we mean by layered architectures, in order to establish some groundwork for what is to come.