MSDN Magazine - December 2008 - (Page 74)

Figure 3 Decoupling the DAL with an Interface namespace DataAccessLayer { // Alias the namespace containing Data Transfer Objects using DTO = DataTransferObjects; public interface IDataProvider { // Retrieve Customers, Products, Orders DTO.Customer[] GetCustomers(); DTO.Product[] GetProducts(); DTO.Order[] GetCustomerOrders(string customerID); // CRUD operations for Order DTO.Order GetOrder(int orderID); DTO.Order CreateOrder(DTO.Order order); DTO.Order UpdateOrder(DTO.Order order); void DeleteOrder(DTO.Order order); } } generating classes on the client for the Entity Framework-specific features, such as EntityKey, EntityKeyMember, EntityObject, and EntityReference. For these reasons you should avoid exposing either LINQ to SQL or Entity Framework tool-generated entities through the DAL and instead return simple DTOs whose sole purpose in life is to carry data across service boundaries. For example, the Order DTO (shown in Figure 2) contains only properties and no methods. All the DTOs are defined in a DataTransferObjects namespace, to distinguish them from tool-generated classes with the same name. A flexible DAL should buffer the Order Service from changes to the underlying persistence technology. Suppose, for example, you decide to use LINQ to SQL to persist objects because you’ve selected SQL Server for your data store and your object model bears a close resemblance to the database schema. But later on, after you’ve written the LINQ to SQL persistence logic, you decide to use another database system, such as Oracle, or you want to take advantage of the Entity Framework’s mapping capabilities to decouple your conceptual and logical schemas. Perhaps a new data access technology comes along that you’d like to use. If you’ve designed a flexible DAL that’s based on a plug-in architecture, you should be able to switch providers on the fly, based on an entry in app.config. To achieve this flexibility, I’ve created an interface called IDataProvider, which has methods for retrieving and updating customer orders, as well as retrieving supporting customer and product information (see Figure 3). The sample application includes two classes that both implement IDataProvider: SqlDataProvider, which uses LINQ to SQL, and EntityDataProvider, which uses the Entity Framework and LINQ to Entities (see Figure 1). You can simply enter the fully qualified class name for the “DataProvider” setting in the DAL’s app.config file, and use the CreateInstance method of the Assembly class to create an instance of the class, casting it to IDataProvider. The Order Service doesn’t care at all about which class implements IDataProvider, giving you the option to use whatever data provider you choose: IDataProvider provider = Assembly.GetExecutingAssembly() .CreateInstance(Settings.Default.DataProvider, true) as IDataProvider; By default, both LINQ to SQL and the Entity Framework will generate entities within the same namespace as the project. But by placing a new “LINQ to SQL Classes” item in a project folder called L2S, the tool will use the folder name as a nested namespace, which helps you differentiate LINQ to SQL entities from your DTO entities. Similarly, placing a new “ADO.NET Entity Data Model” in an L2E project folder causes the Entity Framework entities to be placed in a nested L2E namespace. Alternatively, you could specify the namespace in the property window of the LINQ to SQL and the Entity Framework visual component designers. Here I am making a choice to generate entities both for LINQ to SQL and the Entity Framework, converting the query results to DTOs. There is also the possibility of dispensing with tool-generated entities altogether and mapping the DTOs using XML files. The Entity Framework already uses XML mapping files, but in the first version of the Entity Framework it is not yet possible to achieve pure Figure 4 GetOrder Method Returns a DTO.Order Using LINQ to SQL Framework namespace DataAccessLayer { using DataAccessLayer.L2S; using DTO = DataTransferObjects; public class SqlDataProvider : IDataProvider { public DTO.Order GetOrder(int orderID) { using (NorthwindDataContext db = new NorthwindDataContext (Settings.Default.NorthwindSqlConnection)) { // Set load options DataLoadOptions opts = new DataLoadOptions(); opts.LoadWith (o => o.Customer); opts.LoadWith (o => o.Order_Details); opts.LoadWith (od => od.Product); db.LoadOptions = opts; // Create a DTO.Order from the L2S.Order DTO.Order order = (from o in db.Orders where o.OrderID == orderID select new DTO.Order } } OrderID = o.OrderID, CustomerID = o.CustomerID, CustomerName = o.Customer.ContactName, OrderDate = o.OrderDate, Updated = o.Updated.ToArray(), OrderDetails = (from od in o.Order_Details select new DTO.OrderDetail { OrderID = od.OrderID, ProductID = od.ProductID, ProductName = od.Product.ProductName, Quantity = od.Quantity, UnitPrice = od.UnitPrice, Updated = od.Updated.ToArray() }).ToList() }).Single(); return order; { } } 74 msdn magazine The Entity Framework

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.