A few of us in patterns & practices, with some help from our partners on the Data Platform team have been working on some guidance to help .NET customers build data access layers (DALs). We’ve been hearing for a while that data access on the .NET platform is not intuitive and this confusion is related to technology choices, approaches, design decisions, and implementations. So in response, we putting together some guidance that will hopefully reduce the confusion.

   High-level Description

The role of the DAL is to consume services* that save and retrieve data on behalf of the application. Preferably it’s loosely coupled from the application through interface definitions provided by the application layer. Often the service it’s consuming is a SQL Server (TDS/T-SQL), which implies a relational store, and there are lots of APIs to use to do this (like ADO.NET). Other times – like when you can’t get to the SQL Server or when you’re using something other than a relational store – it’s a different kind of service or one you must build yourself (e.g. REST).

* I draw a distinction between these data services and services that represent course-grained business processes and operations (think SOA, SOAP, and things in that vein). I’m not talking about business services, but I am talking about crossing tiers.

There are quite a few factors that will influence the type of store you use and the services used to interact with the store. While I personally believe our industry needs (and is continuing to go through) a reassessment of various data storage solutions, that’s not the aim of this guidance project – we just don’t have the experience and resources to do an adequate job right now. So this project is scoped to address relational stores and custom data services.

Assuming a relational store, the app will either be able to access the SQL Server directly, or it won’t. This guidance will address both of these scenarios. In the case of being able to go straight to the SQL Server, there are 2 high-level patterns for doing so: object/relational mapping (O/RM), and tabular access. So to summarize the high-level scope of the guidance:

• Direct access to SQL Server
  • 1. Use object/relational mapping (ADO.NET Entity Framework)
  • 2. Use tabular access (Classic ADO.NET)
• No access to SQL Server
  • 3. Consuming data services (ADO.NET Data Services, WCF, etc.)

   Specifics

We’re going to use 2 forms of guidance to illustrate these 3 primary scenarios:

• Reference Implementation (RI). This is a real worldish application that is made up of an ASP.NET MVC web app, a WPF client, and a Silverlight client that each cater to the 3 different roles who use the solution. This RI will only include the O/RM and data services scenario. Tabular access isn’t illustrated since it is better understood. The image below summarizes this online commerce platform.
• Written guidance. This book/PDF will have 2 parts.
  • Architecture. Technology-agnostic topics and cover important concepts, principles, and framing. These topics will cover all 3 scenarios (O/RM, Tabular, and Data Services).
  • Implementation. Technology-specific topics that correlate the architecture topics with how and where they are implemented in the RI.

   Engage!

Like all p&p projects, we’re dropping code after each iteration (2 weeks) on the CodePlex community site and are actively soliciting feedback from YOU about what you need and how we’re doing – the more you engage, the better the guidance will be.

So hop over, download the latest drop, and let us know what you think of how we view the world of .NET data access. We’ve set up a specific page for feedback if you’re curious what questions we have – we’ll continue to build on this list over time. We’re looking forward to your feedback!