Consideraciones de la migración (Entity Framework)

ADO.NET Entity Framework proporciona varias ventajas a una aplicación. Una de las más importantes es la capacidad de utilizar el Entity Data Model (EDM) para separar las estructuras de datos que usa la aplicación del esquema en el origen de datos. De esta forma se pueden realizar más adelante y con facilidad cambios en el modelo de almacenamiento o en el propio origen de datos sin realizar los cambios correspondientes en la aplicación. Para obtener más información sobre las ventajas del uso de Entity Framework, vea Introducción a Entity Framework.

Para aprovecharse de las ventajas de Entity Framework, puede migrar una aplicación existente a Entity Framework. Algunas tareas son comunes a todas las aplicaciones migradas. Estas tareas comunes incluyen actualizar la aplicación para utilizar .NET Framework versión 3.5 Service Pack 1, (SP1) definir el EDM y configurar Entity Framework. Al migrar una aplicación a Entity Framework, se aplican consideraciones adicionales. Estas consideraciones dependen del tipo de aplicación que se migra y de la funcionalidad concreta de la aplicación. Este tema proporciona información para ayudarle a elegir el mejor enfoque que utilizar al actualizar una aplicación existente.

Consideraciones generales de la migración

Las consideraciones siguientes se aplican al migrar una aplicación a Entity Framework:

• Cualquier aplicación que utilice .NET Framework 3.5 se puede migrar a Entity Framework, siempre que el proveedor de datos para el origen de datos que la aplicación use admita Entity Framework.

• Entity Framework puede no admitir toda la funcionalidad de un proveedor de origen de datos, aun cuando ese proveedor sí admita Entity Framework.

• En una aplicación grande o compleja, no es necesario migrar toda la aplicación a Entity Framework a la vez. Sin embargo, cualquier parte de la aplicación que no use Entity Framework aún debe cambiarse cuando el origen de datos cambie.

• La conexión del proveedor de datos que Entity Framework usa se puede compartir con otras partes de la aplicación porque el Entity Framework utiliza los proveedores de datos de ADO.NET para tener acceso al origen de datos. Por ejemplo, Entity Framework utiliza el proveedor SqlClient para tener acceso a una base de datos de SQL Server. Para obtener más información, vea Proveedor de EntityClient para Entity Framework.

Tareas de migración comunes

La ruta para migrar una aplicación existente a Entity Framework depende tanto del tipo de aplicación como de la estrategia de acceso a datos existente. Sin embargo, siempre debe realizar las tareas siguientes al migrar una aplicación existente a Entity Framework.

Nota
Todas estas tareas se realizan automáticamente cuando se usan las herramientas de Entity Data Model con Visual Studio 2008. Para obtener más información, vea Cómo usar el Asistente para Entity Data Model (Entity Framework).

1. Actualice la aplicación.

   Un proyecto creado utilizando una versión anterior de Visual Studio y .NET Framework se debe actualizar para utilizar Visual Studio 2008 SP1 y .NET Framework 3.5 SP1. Para obtener más información, vea Asistente de conversión de Visual Studio.

2. Defina el Entity Data Model (EDM).

   El EDM define las entidades en el modelo conceptual; las estructuras en el origen de datos, por ejemplo las tablas, los procedimientos almacenados y vistas; y la asignación entre las entidades y estructuras del origen de datos. Para obtener más información, vea Cómo definir manualmente un modelo Entity Data Model (Entity Framework).

   Los tipos que se definen en el modelo de almacenamiento deben coincidir con el nombre de los objetos en el origen de datos. Si la aplicación existente expone los datos como objetos, debe asegurarse de que las entidades y las propiedades que se definen en el modelo conceptual coincidan con los nombres de estas clases de datos y propiedades existentes. Para obtener más información, vea Cómo personalizar un modelo Entity Data Model para trabajar con objetos personalizados (Entity Framework).

   Nota
   Entity Data Model Designer se puede utilizar para cambiar el nombre de las entidades en el modelo conceptual de modo que coincidan con los objetos existentes. Para obtener más información, vea Información general sobre ADO.NET Entity Data Model Designer.

3. Defina la cadena de conexión.

   Entity Framework utiliza una cadena de conexión con formato especial al ejecutar las consultas contra un EDM. Esta cadena de conexión encapsula la información sobre los archivos de asignación del EDM y la conexión al origen de datos. Para obtener más información, vea Cómo definir la cadena de conexión (Entity Framework).

4. Configure el proyecto de Visual Studio.

   Las referencias a los ensamblados de Entity Framework y al EDM se deben agregar al proyecto de Visual Studio. Puede agregar estos archivos de asignación al proyecto para asegurarse de que se implementan con la aplicación en la ubicación que se indica en la cadena de conexión. Para obtener más información, vea Cómo configurar manualmente un proyecto de Entity Framework.

Consideraciones para las aplicaciones con objetos existentes

Al migrar una aplicación a Entity Framework, la manera en que migra las clases de datos existentes depende de la lógica de negocio, los métodos personalizados y la validación de las propiedades implementadas en estas clases. Para trabajar con las clases de datos existente, debería seleccionar uno de los enfoques siguientes.

• Si las clases de datos sólo obtienen y establecen propiedades de objetos, reemplace las clases de datos existentes con los tipos de entidad generados por las herramientas de Entity Data Model. Para obtener más información, vea Cómo usar el Asistente para Entity Data Model (Entity Framework).

• Si las clases de datos implementan código de validación personalizado u otra lógica de negocios, migre esta lógica en las clases parciales que generan las herramientas de Entity Data Model. Las herramientas de Entity Data Model generan tipos de entidad como clases parciales. De esta forma se pueden reutilizar los métodos y propiedades convirtiendo las clases existentes en clases parciales. Al hacer esto, debe quitar de la aplicación existente cualquier propiedad que esté duplicada en la clase generada. Para obtener más información acerca de cómo crear clases parciales, vea Personalizar objetos (Entity Framework).

  Para cada propiedad de una clase de datos, las herramientas de Entity Framework generan métodos parciales denominados OnPropertyNameChanging y OnPropertyNameChanged. Puede pasar el código de validación de propiedades existente a estos métodos parciales. Para obtener más información, vea Cómo ejecutar la lógica de negocios durante los cambios de propiedades (Entity Framework).

• Si tiene una cantidad significativa de código personalizado en las clases de datos existentes o desea mantenerlas por otras razones, debería elegir entre lo siguiente:

  • Modifique las clases de datos para que hereden de la clase ComplexObject o EntityObject. Todos los tipos de EDM generados heredan de EntityObject o ComplexObject, y Entity Framework le permite utilizar las clases de datos personalizadas heredando de estas clases base. Así es como se recomienda usar clases de datos personalizadas con un EDM. Para obtener más información, vea Personalizar objetos (Entity Framework).

  • Modifique las clases de datos para implementar un conjunto de interfaces. Haga esto si las clases de datos no pueden heredar de EntityObject o ComplexObject. Para obtener más información acerca de cómo implementar estas interfaces, vea Personalizar objetos (Entity Framework).

Nota
Al utilizar las clases de datos existentes o las clases parciales con un EDM, el nombre de las clases debe coincidir con el nombre de las entidades que se definen en el modelo conceptual. Utilice Entity Designer para cambiar el nombre de las entidades. Para obtener más información, vea Cómo crear y modificar tipos de entidad.

Consideraciones para las aplicaciones que utilizan los proveedores ADO.NET

Los proveedores ADO.NET, como SqlClient, permiten consultar un origen de datos para devolver datos tabulares. Los datos también se pueden cargar en un conjunto de datos de ADO.NET. La lista siguiente describe las consideraciones para actualizar una aplicación que utiliza un proveedor de ADO.NET existente:

• Muestre los datos tabulares utilizando un lector de datos.
  Puede considerar ejecutar una consulta de Entity SQL utilizando el proveedor de EntityClient y enumerando el objeto EntityDataReader devuelto. Haga esto únicamente si la aplicación muestra los datos tabulares mediante un lector de datos y no requiere los medios proporcionados por Servicios de objeto con el fin de materializar los datos en los objetos, realizar el seguimiento de los cambios y efectuar las actualizaciones. Puede continuar utilizando el código de acceso a los datos existente que realiza las actualizaciones en el origen de datos, pero puede utilizar la conexión existente a la que se obtiene acceso desde la propiedad StoreConnection de EntityConnection. Para obtener más información, vea Proveedor de EntityClient para Entity Framework.

• Trabaje con objetos DataSet.
  En Entity Framework, Servicios de objeto proporcionan muchas de las mismas funcionalidades que ofrece un objeto DataSet, incluida la persistencia en memoria, el seguimiento de los cambios, el enlace de los datos y la serialización de los objetos, por ejemplo los datos XML. Para obtener más información, vea Información general de Servicios de objeto (Entity Framework).

  Si Servicios de objeto no proporciona la funcionalidad de DataSet que necesita la aplicación, aún se pueden aprovechar las ventajas de las consultas de LINQ mediante LINQ to DataSet. Para obtener más información, vea LINQ to DataSet.

Consideraciones para las aplicaciones que enlazan datos a los controles

.NET Framework permite encapsular los datos en un origen de datos, por ejemplo un DataSet o un control de origen de datos de ASP.NET, y a continuación enlazar los elementos de la interfaz de usuario a esos controles de datos. La lista siguiente describe las consideraciones del enlace de los controles a los datos de Entity Framework.

• Enlace los datos a los controles.
  Al consultar el EDM, Servicios de objeto devuelve los datos como objetos que son instancias de tipos de entidad. Estos objetos se pueden enlazar directamente a los controles. Este enlace admite actualizaciones. Esto significa que los cambios en los datos de un control, por ejemplo en una fila de DataGridView, se guardan automáticamente en la base de datos al llamar al método SaveChanges.

  Si una aplicación enumera los resultados de una consulta para mostrar los datos en un control de tipo DataGridView o de otro tipo que admite el enlace de datos, puede modificar la aplicación para enlazar el control al resultado de ObjectQuery.

  Para obtener más información, vea Enlazar objetos a controles (Entity Framework).

• Controles de origen de datos de ASP.NET.
  Entity Framework incluye un control de origen de datos diseñado para simplificar el enlace de datos en aplicaciones web de ASP.NET. Para obtener más información, vea Control del origen de datos de Entity Framework.

Otras consideraciones

Las siguientes son consideraciones que se pueden aplicar al migrar tipos específicos de aplicaciones a Entity Framework.

• Aplicaciones que exponen los servicios de los datos.
  Los servicios web y las aplicaciones que se basan en Windows Communication Foundation (WCF) exponen los datos de un origen de datos subyacente utilizando un formato de mensajería de solicitud/respuesta XML. Entity Framework admite la serialización de los objetos de entidad utilizando la serialización de contratos de datos WCF, XML o binaria. Las serializaciones WCF y binaria admiten ambas la serialización completa de los gráficos de objetos. Para obtener más información, vea Servicios web y Entity Data Model (escenarios de aplicación).

• Aplicaciones que utilizan datos XML.
  La serialización de objetos permite crear servicios de datos de Entity Framework. Estos servicios proporcionan datos a las aplicaciones que consumen datos XML, por ejemplo las aplicaciones de Internet basadas en AJAX. En estos casos, considere usar los servicios de datos de ADO.NET. Estos servicios de datos se basan en el EDM y proporcionan acceso dinámico a los datos de entidad utilizando acciones HTTP estándar de Representational State Transfer (REST), como GET, PUT y POST. Para obtener más información, vea Marco de trabajo de los servicios de datos de ADO.NET.

  Entity Framework no admite un tipo de datos XML nativo. Esto significa que cuando una entidad se asigna a una tabla con una columna XML, la propiedad de entidad equivalente para la columna XML es una cadena. Los objetos se pueden desconectar y serializar como XML. Para obtener más información, vea Serializar objetos (Entity Framework).

  Si una aplicación requiere la capacidad de consultar datos XML, todavía puede aprovecharse de las ventajas de las consultas LINQ utilizando LINQ to XML. Para obtener más información, vea LINQ to XML.

• Aplicaciones que mantienen el estado.
  Las aplicaciones web de ASP.NET deben mantener con frecuencia el estado de una página web o de una sesión de usuario. Los objetos de una instancia de ObjectContext pueden almacenarse en el estado de vista del cliente o en el estado de sesión en el servidor, y después recuperarse y se volverse a adjuntar a un nuevo contexto del objeto. Para obtener más información, vea Asociar objetos (Entity Framework).

Vea también

Conceptos

Consideraciones de implementación (Entity Framework)
Terminología de Entity Framework

Otros recursos

Tareas de Entity Framework