Entity Framework 4 / POCO - ¿Dónde comenzar? [cerrado]

183

He estado programando durante un tiempo y he usado LINQ-To-SQL y LINQ-To-Entities anteriormente (aunque cuando usé entidades ha estado en una relación Entidad / Tabla 1-1, es decir, no muy diferente a L2SQL)

He estado leyendo mucho sobre los patrones de inversión de control, unidad de trabajo, POCO y repositorio y me gustaría utilizar esta metodología en mis nuevas aplicaciones.

Donde estoy luchando es encontrar una guía para principiantes clara y concisa para EF4 que no asume el conocimiento de EF1.

Las preguntas específicas que necesito responder son:

Código primero / modelo primero? Pros / contras con respecto a EF4 (es decir, ¿qué sucede si hago el código primero, cambio el código en una fecha posterior y necesito regenerar mi modelo de base de datos? ¿Los datos se conservan, transforman o descartan?)

Suponiendo que voy a usar el código primero (me gustaría ver cómo EF4 convierte eso en un esquema de base de datos), ¿cómo empiezo realmente? Muy a menudo he visto artículos con diagramas de entidad que dicen "Así que este es mi modelo de entidad, ahora voy a ..." - Desafortunadamente, no estoy claro si crearon el modelo en el diseñador, lo guardaron en generar código y luego detuvo cualquier generación de auto-código adicional -o-- ¿Han codificado (POCO)? clases y de alguna manera los importaron a la vista de diseño?

Supongo que lo que realmente necesito es comprender de dónde viene la "magia" y cómo agregarla yo mismo si no solo estoy generando un modelo EF directamente desde una base de datos.

Soy consciente de que la pregunta es un poco vaga, pero no sé lo que no sé, por lo que agradezco cualquier aporte / corrección / aclaración.

No hace falta decir que no espero que nadie se siente aquí y me enseñe EF: me gustaría tener algunos buenos tutoriales / foros / blogs / etc. para novatos de entidad completa

entity-framework entity-framework-4 linq-to-entities poco Básico
fuente
3
tenga mucho cuidado con la vida útil de sus conexiones: bit.ly/fi83NV Es algo que realmente debe tener en cuenta al abstraer contextos en repositorios. Podría parecer que funciona, pero en realidad registra lentamente cada vez más conexiones abiertas
BritishDeveloper
@BRitishDeveloper - Muy buen consejo. Esto realmente nos sorprendió, pero de la manera opuesta: estábamos usando un contenedor de IoC para recuperar repositorios y tuvimos un problema en el que el contexto asignado al repositorio cerraría la conexión después de un período de tiempo prolongado pero no se marcaría como desechado / similar. Eventualmente ampliamos el contexto nosotros mismos con un IsDisposed () que verificó con el estado de eliminación habitual y el estado de conexión que nos permite construir otro si es necesario.
Básico
Otro consejo útil es que cuando se obtiene un nuevo contexto, los objetos asociados con el contexto anterior no tendrán el seguimiento de cambios apropiado y causarán problemas de coincidencia de contexto. Entonces, si tiene una aplicación de larga ejecución y cambia el contexto a mitad ejecución, debe recuperar todas sus entidades. Para hacerlo más interesante, en realidad tuvimos que tener 2 ejecutados uno al lado del otro a veces y terminamos escribiendo un código para mapear entre los 2 muy bien ...
Básico
1
@Basiclife Me encontré con el mismo problema :) He tenido la intención de escribir mis pensamientos sobre la actualización de entidades separadas por un tiempo y me has animado a hacer eso: britishdeveloper.co.uk/2011/03/…
BritishDeveloper

Respuestas:

56

Estos artículos pueden ser de interés ... la serie realmente aborda las ventajas y desventajas de un enfoque POCO.

http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx

http://blogs.msdn.com/b/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading. aspx

http://blogs.msdn.com/b/adonet/archive/2009/06/10/poco-in-the-entity-framework-part-3-change-tracking-with-poco.aspx

En estos artículos, el autor menciona futuros artículos que describen las mejores prácticas para implementar patrones de Repositorio y Unidad de Trabajo, pero no puedo encontrarlos. Estos artículos están bien escritos y me gustaría leer más de este autor.

KellySandwiches
fuente
2
Como alguien que ya se siente cómodo con Entity Framework utilizando el diseñador, esta fue una gran introducción a POCO.
nathanchere
1
Si está buscando el seguimiento de la Unidad de Trabajo, se encuentra en blogs.msdn.com/b/adonet/archive/2009/06/16/…
Mike
7

Le recomiendo que tome media hora más o menos y genere un modelo EF1.0 estable en su VS actual. Eso lo ayudará a comprender las metáforas y los conceptos de EF 4.0. Simplemente cree un simple Cliente, Productos y Pedidos db ... Recomiendo hacer el suyo propio y no usar Northwind.

Chris B. Behrens
fuente
4

Esta es una gran pregunta, pero difícil de mantener actualizada a medida que Entity Framework continúa madurando. Probablemente el mejor lugar para comenzar que se mantendrá actualizado en el futuro es la página EF de Microsoft .

Algunos otros enlaces que encontré útiles mientras buscaba en Google (centrado en Code First):

Dan
fuente
3

Puede tomar el libro de Lerman o algo más simple como "Mapeo relacional de objetos Pro linq". Todos los conceptos siguen siendo los mismos con POCO, excepto que ahora debe desactivar la generación de código y asignarla directamente a su modelo en edmx csdl (o crear su propio generador de POCO). Todos los principios de mapeo son los mismos también. De todos modos, en tiempo de ejecución, está trabajando con un proxy que se deriva de su objeto POCO, por lo que debe preocuparse por el soporte de intercepción (virtualización de sus propiedades POCO).

Voz
fuente
2

Aquí hay un tutorial sobre la plantilla POCO para Entity Framework que se veía bastante bien. También puede consultar el blog del equipo ADO.NET . Si desea comenzar desde el principio (EF v1.0) como base para su conocimiento de EF, encontré el libro de Marco de Entidad de Programación de Julia Lerman muy completo.

DaveB
fuente
Gracias. No había visto el libro, pero he leído los dos enlaces proporcionados. El tutorial de plantilla es útil para explicar cómo se puede agregar funcionalidad adicional a los objetos POCO una vez que se definen (por ejemplo, carga diferida) pero (y es posible que me falte algo obvio aquí) en realidad no explica cómo comenzar (es decir, simplemente crear una clase como se especifica no lo convierte en una entidad ni lo asocia con un modelo) He tenido una experiencia similar con el blog. Sin embargo, consideraré obtener el libro. Parece prometedor. Gracias.
Básico
2
Con respecto al libro de Julia Lerman, vale la pena mencionar que está trabajando en una segunda edición que cubre EF4: learnentityframework.com/LearnEntityFramework/book/… . Recuerdo que leí en alguna parte que la fecha de publicación prevista es mayo de este año, pero ya no puedo encontrar la fuente. También acabo de encontrar este sitio: nakedobjects.net/home/index2.shtml
Slauma
Slauma, el enlace que proporcionó parecía exactamente lo que necesito, excepto que está usando una biblioteca de terceros "Naked Obects" que parece estar ofuscando la complejidad de alguna manera. Por un minuto, pensé que lo había descifrado
Basic
1

Julia Lerman tiene una buena serie de videos introductorios , de unos 10 minutos cada uno. Son introductorios, pero hay muchos consejos prácticos que eliminan algunos obstáculos potenciales de aprendizaje. Me gustó especialmente su demostración de ver el SQL real usando SQL Server Profiler.

David Pope
fuente
1

Si va a usar cenarios desconectados, le recomiendo que lea el libro de Julie Lerman: "Programming DbContext", en el Capítulo especial 4.

Encontré muchos ejemplos en blogs, etc., pero casi todos tratan sobre cenarios conectados.

Yo también estoy empezando. y estos libros me ayudaron mucho. Por cierto, le compré tres libros.

Rodolfo
fuente
0

Wow, muchas respuestas. ¿Qué tal un ejemplo que contiene una versión modificada de plantillas T4 que generan POCO + interfaces + repositorios por completo?

https://entityinterfacegenerator.codeplex.com

Creer2014
fuente
Interesante y útil para probar repositorios / contextos, pero ¿por qué necesitaría abstraer las entidades mismas? Por definición, no deberían tener ningún código funcional dentro de ellos.
Básico
Estás en lo correcto. En su mayoría, las personas no necesitarán tener interfaces separadas. Pero sí ayuda a las personas que desean resolver referencias circulares y desean compartir las interfaces, no las clases reales, con un tercero. Esto ayudará mucho si su empresa necesita pasar una auditoría con integración de terceros que no requiere una implementación detallada al compartir.
Believe2014