linq to sql - not - Migración de LINQ a SQL a Entity Framework 4.0-Consejos, documentación, etc.

not in linq

Question

Probé EF nuevamente en .NET 3.5 SP1, y fui uno de los muchos que se frustraron y decidieron aprender LINQ to SQL. Ahora que sé que EF es el camino "elegido" hacia adelante, además de que EF 4.0 tiene algunas características nuevas interesantes, me gustaría migrar mi aplicación a EF 4.0.

¿Alguien puede sugerir algún buen recurso que esté específicamente dirigido a la migración de 4.0 y L2S? NOTA: Puedo encontrar muchos blogs y artículos relacionados con la migración de L2S a EF en .NET 3.5, pero creo que muchos de ellos fueron obviamente obsoletos y poco útiles para alguien que usa 4.0.

Realmente me gustaría todo lo que pueda conseguir bajo el capó; Quiero realmente irme sintiendo que conozco EF 4.0 de la manera que conozco actualmente L2S 3.5.

TIA!

Answer 1

He encontrado esta plantilla de conversión , es para la beta1 (2010). No parece haber una versión más nueva. Mabe puedes cambiarlo para que funcione con el RTM.

No lo he usado yo mismo.

Answer 2

He hecho un montón de este mismo tipo de conversión y FWIW, diría que hay más similitudes que diferencias. No creo que haya ninguna documentación definitiva que te haga sentir como un experto en EF4, más allá de lo que ya existe ...

http://msdn.microsoft.com/en-us/library/ex6y04yf(VS.100).aspx

Lo que puedo darles son los "errores" más obvios. Específicamente, Linq2Sql quería combinar la capa de negocios y la capa de datos mucho más obviamente. Realmente te empujó a crear tus propias clases parciales. Podría seguir y seguir por el camino, pero la razón más específica es la forma en que el asignador individual creará propiedades públicas primarias y secundarias para todas las relaciones.

Si intenta usar cualquier tipo de serialización contra este modelo, le gustará encontrarse con problemas de referencia circulares, ya que un serializador se mueve de un padre a un hijo y luego regresa al padre ya que el comportamiento de serialización de Linq2Sql incluye automáticamente a todos los niños en el gráfico. Esto también puede ser realmente molesto cuando intenta obtener un registro del cliente para verificar la propiedad "Nombre" y obtener automáticamente todos los registros de pedidos relacionados incluidos en el gráfico. Puede configurar estas propiedades de navegación principal y secundaria para que sean "públicas" o "internas", lo que significa que si desea acceder a ellas, pero no quiere que los serializadores creen automáticamente referencias circulares, es casi necesario que tenga acceso parcial. clases

Una vez que empiezas por la ruta parcial de clases, generalmente solo continúas el patrón y eventualmente comenzarás a agregar métodos de ayuda para acceder a tus datos en tus clases de entidad individuales. Además, como Linq2Sql DataContext es más liviano, a menudo hay personas que utilizan algún tipo de patrón Singleton o Repository para su contexto. Esto no se ve tanto en absoluto con EF 3.5 / 4.

Entonces, digamos que tiene un entorno similar al descrito y quiere comenzar a convertir. Bueno, necesita saber cuándo se va a crear / destruir su DataContext ... algunas personas simplemente iniciarán cada método de Capa de negocios con una instrucción using () y dejarán que el contexto viva durante toda la vida del método. Obviamente, esto significa que puede entrar en algunas situaciones difíciles que requieren agregar .ToList () o algún otro método de extensión al final de sus preguntas, puede tener una colección de sus objetos en memoria para pasar a un método secundario o lo que sea, e incluso entonces puede tener problemas al intentar actualizar las entidades en un contexto del cual no se recuperaron originalmente.

También deberá averiguar cómo gran parte del BusinessLogic incorporado en sus clases parciales de Linq2Sql saldrá a otra capa si no trata explícitamente con las operaciones de datos. Esto no será indoloro a medida que descubras cuándo necesitas / no necesitas tu contexto, pero es lo mejor ...

A continuación, tendrá que tratar con la situación del gráfico de objetos. Debido a la diferencia en la forma en que funciona la carga perezosa (lo hicieron configurable en EF 4.0 para que se comporte más como Linq2Sql para aquellos que lo querían) probablemente necesitará verificar cualquier uso implícito de objetos secundarios en la gráfica de su Linq2Sql implementación y verifique que ahora no requiera un .Include () o un .Load () explícitos para obtener los objetos secundarios en el gráfico.

Finalmente, deberá decidir una solución de serialización en general. De forma predeterminada, los atributos DataContracts y DataMember que se generan como parte de un modelo EF funcionan muy bien con WCF, pero no del todo bien con el XmlSerializer utilizado para cosas como el antiguo .asmx WebServices. Incluso en esta circunstancia, es posible que pueda salirse con la suya si nunca necesita serializar objetos secundarios a través del cable. Ya que generalmente ese no es el caso, usted querrá mudarse a WCF si tiene una SOA más, lo que agregará toda una nueva cantidad de oportunidades, sin embargo, dolores de cabeza.

Para lidiar con la situación de las clases parciales y el elevado DataContext e incluso los problemas de serialización, hay una serie de nuevas plantillas de generación de código disponibles con EF 4.0. La plantilla POCO-Entidad tiene mucha gente entusiasmada ya que crea clases de POCO, tal como cabría esperar (el problema es que excluye cualquier atributo de clase o miembro para WCF, etc., etc.). Además, el modelo de entidades de seguimiento automático resuelve el problema del contexto, ya que puede pasar sus entidades y recordarlas cuándo y cómo se actualizaron, de modo que puede crear / eliminar sus contextos mucho más libremente (como Linq2Sql). Como otra ventaja adicional, esta plantilla es la plantilla para ir a WCF o cualquier cosa que se construya en WCF como RIA Services o WCF Data Services, por lo que ya tienen resueltos los atributos [DataContract], [DataMember] y [KnownType].

Aquí hay un enlace a la plantilla de POCO (no incluida fuera de la caja): (EDITAR: no puedo publicar dos hipervínculos, así que simplemente visite el sitio web de la galería de visualstudio y busque "ADO.NET C # POCO Entity Generator")

Asegúrese de leer el enlace en el blog del equipo de ADO.net sobre cómo implementar esto. Es posible que le guste la parte de dividir su contexto y sus entidades en proyectos / ensamblajes separados si cae en la categoría de Servicio Web vs. Servicio WCF. La generación de proxy "Agregar referencia de servicio ..." no hace espacios de nombres de la misma manera que "Agregar referencia web ...", por lo que le gustaría hacer referencia al conjunto de clase de entidad en su aplicación cliente para que pueda "excluir" tipos de bibliotecas de referencia "o lo que sea en sus referencias de servicio para que no obtenga muchas referencias ambiguas de múltiples servicios que utilizan el mismo modelo EF y exponen esas entidades ...

Sé que esto es largo e incoherente, pero estos pequeños errores fueron un problema más importante para mí que recordar usar context.EntityCollection.AddObject () en lugar de context.EntityCollection.InsertOnSubmit () y context.SaveChanges () en lugar de contexto. Presentar cambios()...

Answer 3

Para EF Code First, se trata principalmente de ingeniería inversa de las tablas existentes en las clases EF. EF Power Tools ahora hace esto por ti:

http://msdn.microsoft.com/en-us/data/jj200620.aspx

El resto es el trabajo obvio de modificar su código existente para usar esas clases generadas para hablar con la base de datos en lugar de LINQ a SQL.