¿Trabajando con el marco de la entidad, forma preferida?

Question

Supongamos que hemos creado el modelo Entidades, ¿cuál es la forma preferida de trabajar con él? Estoy personalmente no podría hacer en mi mente ..

1. Usando ModelAdapter:

   public statiс Product[] GetProducts() 
   { 
        using(Entities ctx = new Entities()) 
        { 
          return ctx.Product.ToArray(); 
        } 
   } 
   
   
   
   Product[] ps = ModelAdapter.GetProducts(); 
   // ... 
   ModelAdapter.UpdateProduct(p); 
   

   • ve limpio;
   • pero, el contexto se crea/libera muchas veces, los objetos pierden contacto con el contexto;

2. Usando contexto en el lugar:

   using(Entities ctx = new Entities()) 
   { 
        Product[] ps = ctx.Product.ToArray(); 
   
        // ... 
   
        ctx.SaveChanges(); 
   } 
   

   • efectiva
   • pero, código se vuelve desordenado

3. modo mixto, el compromiso?

métodos

4. Extensión:

   using(Entities ctx = new Entities()) 
   { 
       Product[] ps = ctx.GetProducts(); 
       // ... 
       ctx.UpdateProduct(p); 
   } 
   

En realidad ahora, estoy tratando de enfoque # 4, la aplicación de métodos de utilidad como extensiones al contexto. Entonces puedo usar un contexto y hacer muchas llamadas a este contexto.

Answer 1

Generalmente use cualquier cosa que se adapte a sus necesidades, que sea fácil de mantener y que se ajuste a la complejidad de su aplicación. Algunos puntos que usted debe pensar:

• Never share context among requests, utilizan un contexto por la petición, por acción o por el método en función de sus necesidades.
• Si desea probar la unidad de su aplicación, puede encontrar que los métodos estáticos y algunas veces también los métodos de extensión pueden ser un problema. Pero la aplicación de prueba con EF es a separate problem.
• Si desea modificar o insertar más elementos en una sola unidad de trabajo, puede encontrar que un contexto por método no es lo que necesita
• Muchos desarrolladores prefieren utilizar el patrón de repositorio para separar el acceso a las funciones de EF del resto de la aplicación. Tiene su propio pros and cons.

Answer 2

Al desarrollar aplicaciones web he estado utilizando un contexto compartido que se crea por solicitud web. Luego puede usar su enfoque "ModelAdapter" y conservar la encapsulación, pero aún operar en el mismo contexto. Lo he usado mucho y no he tenido ningún problema.

Answer 3

Normalmente me gustaría una implementación donde las complejidades de tratar con EF se abstraigan utilizando el Repository pattern, pero tienen el contexto vivo el tiempo que lo necesito. (Escenario 3)

Por "tanto tiempo como lo necesite" me refiero a la duración de la llamada de servicio. No quiero que el ObjectContext persista a través de llamadas de servicio múltiples, ya que tendría que lidiar con su estado. El costo de crear un nuevo ObjectContext es insignificante.

Creo que de muchas maneras su ModelAdapter también abstrae las complejidades de EF, sin embargo, en función de su naturaleza estática, puede/tendrá problemas en escenarios concurrentes si decide persistir el ObjectContext. La forma en que se implementa ahora puede no brindarle la flexibilidad que necesita para consultas más complejas (uniéndose al Pedido < -> OrderDetail < -> Producto por ejemplo).