poco - near - html5 alt

Explicación de POCO

Question

Me pregunto si alguien puede dar una explicación sólida (con ejemplo) de POCO (objeto CLR antiguo simple). Encontré una breve explicación en Wikipedia pero realmente no da una explicación sólida.

Answer 1

Debe proporcionar más detalles, como el contexto en el que planea usar POCO. Pero la idea básica es que creará objetos simples que contienen solo los datos / códigos que son necesarios. Estos objetos no contendrían ningún "equipaje" como anotaciones, métodos adicionales, clases base, etc. que de otra forma podrían ser requeridos por (por ejemplo) un marco.

Answer 2

Ejemplo de un POCO:

class Person {
public string FirstName { get; set; }
public string LastName { get; set; }
public string EmailAddress { get; set; }
}

Answer 3

En lugar de llamarlos POCO , prefiero llamarlos objetos ignorantes de persistencia .

Debido a que su trabajo es simple, no necesitan preocuparse por para qué se usan o cómo se usan.

Personalmente creo que los POCO son solo otra palabra de moda (como la Web 2.0, no me refiero a eso) para una clase pública con propiedades simples.

Siempre he estado utilizando este tipo de objetos para mantener el estado comercial.

Los principales beneficios de los POCO se ven realmente cuando empiezas a usar cosas como el patrón de repositorio, los ORM y la inyección de dependencia.

En otras palabras, puede crear un ORM (digamos EF) que extraiga datos de algún lugar (db, servicio web, etc.) y luego proyecte estos datos en objetos (POCO).

Estos objetos se pueden pasar más abajo en la pila de aplicaciones a la capa de servicio, y luego a la capa web.

Entonces, si un día decide cambiarse a nHibernar, no debería tener que tocar sus POCO en absoluto, lo único que debe cambiar es el ORM.

De ahí el término ''persistencia ignorante'': no ​​les importa para qué se usan o cómo se usan.

Para resumir, los pros:

• Permite un mecanismo de almacenamiento simple para los datos, simplifica la serialización / el paso a través de las capas
• Va de la mano con la inyección de dependencia, el patrón de repositorio y los ORM. Flexibilidad.
• Minimiza la complejidad y las dependencias de otras capas. (Las capas superiores solo se preocupan por los POCO, a los POCO no les importa nada). Bajo acoplamiento
• Prueba simple (no se requiere aplastamiento para pruebas de dominio).

Espero que ayude.