Consideraciones de 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 más información acerca de las ventajas de usar Entity Framework, consulte Introducción a Entity Framework y Entity Data Model.
Para aprovecharse de las ventajas de Entity Framework, puede migrar una aplicación existente a esta solución. Algunas tareas son comunes a todas las aplicaciones migradas. Estas tareas comunes incluyen actualizar la aplicación para que utilice .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, hay que aplicar 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 del 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 ya que Entity Framework utiliza los proveedores de datos de ADO.NET para acceder 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, consulte 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 Visual Studio 2008. Para más información, consulte Cómo: Usar el Asistente para Entity Data Model.
Actualice la aplicación.
Se debe actualizar un proyecto creado con una versión anterior de Visual Studio y .NET Framework para usar Visual Studio 2008 SP1 y .NET Framework a partir de la versión 3.5 SP1.
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 más información, consulte Cómo: Definir manualmente los archivos de asignación y de modelo.
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 más información, consulte Cómo: Personalizar el modelado y asignación de archivos para trabajar con objetos personalizados.
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 más información, consulte Entity Data Model Designer.
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.
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 más información, consulte 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 con omisión de persistencia. En la mayoría de los casos, los objetos existentes pueden funcionar con Entity Framework realizando pequeños cambios. Para más información, consulte Trabajar con entidades POCO. Puede migrar también una aplicación a Entity Framework y utilizar las clases de datos generadas por las herramientas de dicha solución. Para más información, consulte Cómo: Usar el Asistente para Entity Data Model.
Consideraciones para las aplicaciones que utilizan los proveedores ADO.NET
Los proveedores de 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 la ejecución de una consulta de Entity SQL mediante el proveedor de EntityClient y la enumeración mediante 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 que proporciona 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, consulte Proveedor de EntityClient para Entity Framework.
Trabaje con objetos DataSet.
Entity Framework proporciona 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 más información, consulte Trabajar con objetos.
Aunque Entity Framework no proporcione la funcionalidad de DataSet que necesita la aplicación, se pueden aprovechar las ventajas de las consultas de LINQ mediante LINQ to DataSet. Para 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 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<T>.
Para más información, consulte Enlazar objetos a controles.
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 más información, consulte Información general sobre el control de servidor web EntityDataSource.
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 más información, consulte Crear aplicaciones de n capas.
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, como las aplicaciones de Internet basadas en AJAX. En estos casos, considere usar los servicios de datos de WCF. Estos servicios de datos se basan en Entity Data Model y proporcionan acceso dinámico a los datos de entidad a través de acciones HTTP de Transferencia de datos de representación (REST) estándar, como GET, PUT y POST. Para obtener más información, vea WCF Data Services 4.5.
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 más información, consulte Serializar objetos.
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 más información, consulte LINQ to XML (C#) o LINQ to XML (Visual Basic).
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 más información, consulte Adjuntar y desasociar objetos.