Partager via

Data Access Guidance

  • Article

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

overview

   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!

Comments

  • Anonymous
    July 26, 2009
    For most developers, their IDEs are still in VS 2008 or under. Putting Data Access Guidance under VS 2010 beta means you don't want almost all of us to take a look at it. No serious developer would install beta on the working  station. Thanks, Chester in Calgary

  • Anonymous
    July 26, 2009
    To Don: Seems like an interesting project, will go onto the never ending list of things I should be reading :) (Just working my way through Code Complete 2 at the moment) You mentioned an ASP.NET MVP app where I think you meant MVC? To Chester: These days you have the option to setup a VPC image and install it into there for testing purposes, but yes I agree they should do a vs2008 project if this is only released in vs2010.

  • Anonymous
    July 27, 2009
    Thanks Harry, you're right and I'll be sure to fix that right away. Thanks. Chester, thanks for your comment. I should have suspected this would be an FAQ and cut it off at the pass. Because I'd like to share our rationale, I'll do so in a separate post than here in the comments (so it's easier to refer to later). Don

  • Anonymous
    July 30, 2009
    I like the idea of having a guide for building Data access layer. I got a litle confuse because you are just saying that the app uses the MVC. From what I know MVC is a UI pattern, so from my perspective you will need a BL down from the UI pattern and below the DACL. Same hint for Astoria Stuff... if I use it? where my BL will be placed? Best Regards