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 modelo conceptual 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 Información general de Entity Framework y Entity Data Model.

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 a partir de la versión 3.5 Service Pack 1, (SP1) definir los modelos y la asignación, 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 a partir de la versión 3.5 SP1 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 a partir de .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 SP1 y .NET Framework a partir de la versión 3.5 SP1.

2. Defina los modelos y la asignación.

   Los archivos de modelo y asignación definen 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 los archivos de asignación y modelo (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 archivos de asignación y modelado 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 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 sobre un modelo conceptual. Esta cadena de conexión encapsula la información sobre los archivos de modelo y asignación 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 a los archivos de modelo y asignación 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

A partir de .NET Framework 4, Entity Framework admite objetos CLR antiguos (POCO), también llamados objetos que ignoran la persistencia. En la mayoría de los casos, los objetos existentes pueden funcionar con Entity Framework realizando pequeños cambios. Para obtener más información, vea Trabajar con entidades POCO (Entity Framework). Puede migrar también una aplicación a Entity Framework y utilizar las clases de datos generadas por las herramientas de Entity Framework. Para obtener más información, vea Cómo usar el Asistente para Entity Data Model (Entity Framework).

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 Entity Framework 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.

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

  Si Entity Framework 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.

• Enlazar datos a controles.
  Al consultar el modelo conceptual, Entity Framework 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 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 Crear aplicaciones de n niveles (Entity Framework).

• 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 Entity Data Model 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 ADO.NET Data Services.

  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 y desasociar objetos (Entity Framework).

Vea también

Conceptos

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