Migration Considerations (Entity Framework)

The ADO.NET Entity Framework provides several benefits to an existing application. One of the most important of these benefits is the ability to use the Entity Data Model (EDM) to separate data structures used by the application from the schema in the data source. This enables you to easily make future changes to the storage model or to the data source itself without making compensating changes to the application. For more information about the benefits of using the Entity Framework, see Introducing the Entity Framework.

To take advantage of the benefits of the Entity Framework, you can migrate an existing application to the Entity Framework. Some tasks are common to all migrated applications. These common tasks include upgrading the application to use the .NET Framework version 3.5 Service Pack 1 (SP1), defining the EDM, and configuring the Entity Framework. When you migrate an application to the Entity Framework, there are additional considerations that apply. These considerations depend on the type of application being migrated and on the specific functionality of the application. This topic provides information to help you choose the best approach to use when you upgrade an existing application.

General Migration Considerations

The following considerations apply when you migrate any application to the Entity Framework:

• Any application that uses the .NET Framework 3.5 can be migrated to the Entity Framework, as long as the data provider for the data source that is used by the application supports the Entity Framework.

• The Entity Framework may not support all the functionality of a data source provider, even if that provider supports the Entity Framework.

• For a large or complex application, you are not required to migrate the whole application to the Entity Framework at one time. However, any part of the application that does not use the Entity Framework must still be changed when the data source changes.

• The data provider connection used by the Entity Framework can be shared with other parts of your application because the Entity Framework uses ADO.NET data providers to access the data source. For example, the SqlClient provider is used by the Entity Framework to access a SQL Server database. For more information, see EntityClient Provider for the Entity Framework.

Common Migration Tasks

The path to migrate an existing application to the Entity Framework depends both on the type of application and on the existing data access strategy. However, you must always perform the following tasks when you migrate an existing application to the Entity Framework.

1. Upgrade the application.

   A project created by using an earlier version of Visual Studio and the .NET Framework must be upgraded to use Visual Studio 2008 SP1 and the .NET Framework 3.5 SP1. For more information, see Visual Studio Conversion Wizard.

2. Define the Entity Data Model (EDM).

   The EDM defines entities in the conceptual model; structures in the data source, such as tables, stored procedures, and views; and the mapping between the entities and data source structures. For more information, see How to: Manually Define an Entity Data Model (Entity Framework).

   Types that are defined in the storage model must match the name of objects in the data source. If the existing application exposes data as objects, you must ensure that the entities and properties that are defined in the conceptual model match the names of these existing data classes and properties. For more information, see How to: Customize an Entity Data Model to Work with Custom Objects (Entity Framework).

   Note

   The Entity Data Model Designer can be used to rename entities in the conceptual model to match existing objects. For more information, see ADO.NET Entity Data Model Designer Overview.

3. Define the connection string.

   The Entity Framework uses a specially formatted connection string when executing queries against an EDM. This connection string encapsulates information about the EDM mapping files and the connection to the data source. For more information, see How to: Define the Connection String (Entity Framework).

4. Configure the Visual Studio project.

   References to Entity Framework assemblies and the EDM must be added to the Visual Studio project. You can add these mapping files to the project to ensure that they are deployed with the application in the location that is indicated in the connection string. For more information, see How to: Manually Configure an Entity Framework Project.

Considerations for Applications with Existing Objects

When you migrate an application to the Entity Framework, the way that you migrate existing data classes depends on the business logic, custom methods, and property validation implemented in these classes. You should select one of the following approaches for working with existing data classes.

• If your data classes only get and set object properties, replace your existing data classes with the entity types generated by the Entity Data Model tools. For more information, see How to: Use the Entity Data Model Wizard (Entity Framework).

• If your data classes implement custom validation code or other business logic, migrate this logic into the partial classes that are generated by the Entity Data Model tools. The Entity Data Model tools generate entity types as partial classes. This enables you to reuse methods and properties by converting your existing classes into partial classes. When you do this, you must remove from the existing application any properties that are duplicated in the generated class. For more information about how to create partial classes, see Customizing Objects (Entity Framework).

  For each property of a data class, the Entity Framework tools generate partial methods named OnPropertyNameChanging and OnPropertyNameChanged. You can move your existing property validation code into these partial methods. For more information, see How to: Execute Business Logic During Property Changes (Entity Framework).

• If you have a significant amount of custom code in your existing data classes or you want to keep your existing data classes for other reasons, you should do one of the following:

  • Modify your data classes to inherit from the EntityObject or the ComplexObject class. All generated EDM types inherit from EntityObject or ComplexObject, and the Entity Framework enables you to use custom data classes by inheriting from these base classes. This is the recommended way to use custom data classes with an EDM. For more information, see Customizing Objects (Entity Framework).

  • Modify your data classes to implement a set of interfaces. Do this if your data classes cannot inherit from EntityObject or ComplexObject. For more information about how to implement these interfaces, see Customizing Objects (Entity Framework).

Considerations for Applications that Use ADO.NET Providers

ADO.NET providers, such as SqlClient, enable you to query a data source to return tabular data. Data can also be loaded into an ADO.NET DataSet. The following list describes considerations for upgrading an application that uses an existing ADO.NET provider:

• Displaying tabular data by using a data reader.
  You may consider executing an Entity SQL query using the EntityClient provider and enumerating through the returned EntityDataReader object. Do this only if your application displays tabular data using a data reader and does not require the facilities provided by Object Services for materializing data into objects, tracking changes, and making updates. You can continue to use existing data access code that makes updates to the data source, but you can use the existing connection accessed from the StoreConnection property of EntityConnection. For more information, see EntityClient Provider for the Entity Framework.

• Working with DataSets.
  In the Entity Framework, Object Services provides many of the same functionalities provided by DataSet, including in-memory persistence, change tracking, data binding, and serializing objects as XML data. For more information, see Object Services Overview (Entity Framework).

  If Object Services does not provide the functionality of DataSet needed by your application, you can still take advantage of the benefits of LINQ queries by using LINQ to DataSet. For more information, see LINQ to DataSet.

Considerations for Applications that Bind Data to Controls

The .NET Framework lets you encapsulate data in a data source, such as a DataSet or an ASP.NET data source control, and then bind user interface elements to those data controls. The following list describes considerations for binding controls to Entity Framework data.

• Binding data to controls.
  When you query the EDM, Object Services returns the data as objects that are instances of entity types. These objects can be bound directly to controls, and this binding supports updates. This means that changes to data in a control, such as a row in a DataGridView, automatically get saved to the database when the SaveChanges method is called.

  If your application enumerates the results of a query to display data in a DataGridView or other type of control that supports data binding, you can modify your application to bind the control to the result of an ObjectQuery.

  For more information, see Binding Objects to Controls (Entity Framework).

• ASP.NET data source controls.
  The Entity Framework includes a data source control designed to simplify data binding in ASP.NET Web applications. For more information, see Entity Framework Data Source Control.

Other Considerations

The following are considerations that may apply when you migrate specific types of applications to the Entity Framework.

• Applications that expose data services.
  Web services and applications that are based on the Windows Communication Foundation (WCF) expose data from an underlying data source by using an XML request/response messaging format. The Entity Framework supports the serialization of entity objects by using binary, XML, or WCF data contract serialization. Binary and WCF serialization both support full serialization of object graphs. For more information, see Web Services and the Entity Data Model (Application Scenarios).

• Applications that use XML data.
  Object serialization enables you to create Entity Framework data services. These services provide data to applications that consume XML data, such as AJAX-based Internet applications. In these cases, consider using ADO.NET Data Services. These data services are based on the EDM and provide dynamic access to entity data by using standard Representational State Transfer (REST) HTTP actions, such as GET, PUT, and POST. For more information, see ADO.NET Data Services Framework.

  The Entity Framework does not support a native-XML data type. This means that when an entity is mapped to a table with an XML column, the equivalent entity property for the XML column is a string. Objects can be disconnected and serialized as XML. For more information, see Serializing Objects (Entity Framework).

  If your application requires the ability to query XML data, you can still take advantage of the benefits of LINQ queries by using LINQ to XML. For more information, see LINQ to XML.

• Applications that maintain state.
  ASP.NET Web applications must frequently maintain the state of a Web page or of a user session. Objects in an ObjectContext instance can be stored in the client view state or in the session state on the server, and later retrieved and reattached to a new object context. For more information, see Attaching Objects (Entity Framework).

See Also

Concepts

Deployment Considerations (Entity Framework)
Entity Framework Terminology

Other Resources

Entity Framework Tasks