Resources
Data Access has been discontinued. Please refer to this page for more information.

Migration Considerations

This article is relevant to entity models that utilize the deprecated Visual Studio integration of Telerik Data Access. The current documentation of the Data Access framework is available here.

Telerik Data Access provides several benefits to an existing application. One of the most important of these benefits is the ability to use a conceptual model 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 domain model or to the data source itself without making compensating changes to the application.

To take advantage of the benefits of Telerik Data Access, you can migrate an existing application to Telerik Data Access. Some tasks are common to all migrated applications. These common tasks include upgrading the application to use the .NET Framework starting with version 3.5 Service Pack 1 (SP1), defining models and mapping, and configuring Telerik Data Access. When you migrate an application to Telerik Data Access, there are additional considerations that apply. These considerations depend on the type of application that is 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 Telerik Data Access:

  • Any application that uses the .NET Framework starting with version 3.5 SP1 can be migrated to use the Telerik Data Access Visual Designer, as long as the data provider for the data source that is used by the application supports Telerik Data Access.
  • Telerik Data Access may not support all the functionality of a data source provider, even if that provider supports Telerik Data Access.
  • For a large or complex application, you are not required to migrate the whole application to Telerik Data Access at one time. However, any part of the application that does not use Telerik Data Access must still be changed when the data source changes.
  • The data provider connection used by Telerik Data Access can be started with other parts of your application because Telerik Data Access uses ADO.NET data providers to access the data source.

Common Migration Tasks

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

All of these tasks are performed automatically when you use Telerik Data Access Model Tools starting with Visual Studio 2008 SP1. For more information, see Telerik Data Access Model Tools.

  1. Upgrade the application - a project created by using an earlier version of Visual Studio and .NET Framework must be upgraded to use Visual Studio 2008 SP1 and the .NET Framework starting with version 3.5 SP1.
  2. Define the domain models - the domain model defines persistent classes in the conceptual model; structures in the data source, such as tables, stored procedures, and views; and the mapping between the persistent classes and data source structures. For more information, see Database First Scenario.
    If the existing application exposes data as objects, you must ensure that the persistent classes and properties that are defined in the conceptual model match the names of these existing data classes and properties.
  3. Define the connection string - Telerik Data Access uses a specially formatted connection string when executing queries against the conceptual model. This connection string encapsulates information about the domain model and the connection to the data source.
  4. Configure the Visual Studio project - references to Telerik Data Access assemblies and the domain model must be added to the Visual Studio project.

Considerations for Applications that Bind Data to Controls

Telerik Data Access lets you encapsulate data in a data source, and then bind user interface elements to those data controls. The following list describes considerations for binding controls to data.

Binding data controls

When you query the conceptual model, Telerik Data Access returns the data as objects that are instances of persistent classes. These objects can be bound directly to controls, and this binding supports updates. Which means that changes to data in a control, such as a row in a DataGridView control, 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 a query.

Note that the persistent classes generated by the Visual Designer, do not implement the INotifyPropertyChanged interface. Which means that changes to the business objects are not automatically propagated to the user controls.

Other Considerations

The following are considerations that may apply when you migrate specific types of applications to Telerik Data Access.

  • 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. Telerik Data Access supports the serialization of objects by using binary, XML, or WCF data contract serialization. Binary and WCF serialization both support full serialization of object graphs.
  • Applications that use XML data - object serialization enables you to create Telerik Data Access data services. These services provide data to applications that consume XML data, such as Silverlight applications. In these cases, consider using WCF Data Services. These data services are based on the generated domain model and provide dynamic access to data by using standard Representational State Transfer (REST) HTTP actions, such as GET, PUT, and POST.
  • 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 OpenAccessContext instance can be stored in the client view state or in the session state on the server, and later retrieved and re-attached to a new OpenAccessContext.