MSDN Magazine - December 2008 - (Page 72)

S O A D AtA A c c e S S Flexible Data Access With LINQ To SQL And The Entity Framework Anthony Sneed With the releases of LINQ to SQL and the ADO.NET Entity Framework, developers now have two products from Microsoft designed to reduce the impedance mismatch that exists between the worlds of relational data and object-oriented programming. Each of these eliminates much of the plumbing code you would otherwise have to write to perform object persistence. However, incorporating these object relational mapping (ORM) technologies into a service-oriented application architecture presents a whole new set of challenges for the application developer. For instance, how do you create a data access layer (DAL) that abstracts object persistence from other parts of the application, so that you can swap out one ORM provider for another should the this article discusses: • LINQ to SQL • ADO.Net entity Framework, service-oriented architecture • Data transfer objects • Persistence, updates, and change tracking technologies discussed: LINQ to SQL, ADO.Net entity Framework, and SOA code download: code.msdn.microsoft.com/mag200812SOADAL 72 msdn magazine need arise? How do you track changes to entities without requiring LINQ to SQL or the Entity Framework on the client? How do you perform inserts, updates, and deletes for multiple entities in a single transaction with just one trip to the service? Here I’ll provide you with a roadmap and make some suggestions for how you can address these issues. I’ll start by creating a DAL for processing orders from the Northwind sample database. The DAL will rely on an interface with two implementations, one using LINQ to SQL, and the other using the Entity Framework (see Figure 1). Both LINQ to SQL and the Entity Framework have tools that generate entities based on a database schema, but rather than using these entities, the DAL will only expose data transfer objects (DTOs) that are basically ignorant when it comes to their own persistence. LINQ to SQL and the Entity Framework each have different methods for persisting disconnected entities, depending on whether you are creating a new entity or updating an existing one. Therefore, in order to invoke the appropriate API, you need to know the state of the entity beforehand. If, for example, you have an UpdateOrder method that accepts an order with order details, you could add three parameters to the UpdateOrder method accepting created, updated, and deleted order details. However, this tends to pollute the method signature with plumbing details. Alternatively, you could pass change state information out-ofband, for instance, in a SOAP or HTTP header, but this could couple http://code.msdn.microsoft.com/mag200812SOADAL

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.