SOA data access: Flexible data access using LINQ to SQL and the Entity Framework

This article supporting source code

This article uses the following techniques:

LINQ to SQL, ADO. NET Entity Framework and SOA

Directory

To create a data access layer

Persisting individual objects

Tracking changes across service boundaries

Configuring clients

Summarize

To date, Microsoft has published two products for developers that are designed to reduce the impedance mismatch between relational data domains and object-oriented programming: LINQ to SQL and Ado.net Entity Framework. With either product, you do not have to write most of the probe code to achieve object persistence. However, applying these object-relational mapping (ORM) technologies to service-oriented application architectures poses a new challenge for application developers.

For example, how to create a data access layer (DAL) that separates object persistence from other parts of the application so that you can swap out another provider if needed using an ORM provider. How do I track changes to an entity without a LINQ to SQL or Entity Framework installed by the client? How can you insert, update, and delete multiple entities in a single transaction once by simply invoking the service?

In this article, I'll make a brief introduction and provide some advice on how to solve the above problems. First, I'll create a DAL for processing orders based on the Northwind sample database. Two implementations of the DAL (one using LINQ to SQL, one using the Entity Framework) depend on an interface (see Figure 1). Both LINQ to SQL and the Entity Framework have tools that build entities based on the database schema, but the DAL does not use these entities, but rather exposes only data transfer objects (DTO) that are typically ignored when it comes to the persistence of itself.

Figure 1 Service-oriented architecture for order Processing applications