¿Para qué puedo usar POCO?

Question

He leído algunos artículos sobre POCO en el marco de la Entidad pero todavía no entiendo para qué puedo usarlo. ¿Cómo puede POCO beneficiar a mis proyectos?

Answer 1

POCO standards for "Plain Old Clr Object". Se refiere a un estilo de arquitectura ORM donde todo el trabajo para persistir y cargar los datos del almacén de datos es realizado por el sistema sin que el objeto sepa lo que le está sucediendo. Esto significa que el ORM puede admitir totalmente plain objetos que no han sido modificados de ninguna manera con el ORM en mente. Un ORM que admita la persistencia de POCOs no requerirá que su clase herede de una base específica, implemente cualquier interfaz o incluso etiquete métodos con cualquier atributo.

Todo lo contrario de esto (a veces conocido como Objetos de acceso a datos o DAO) es cuando todo el almacenamiento lo maneja el propio objeto, sabe exactamente cómo serializarlo y almacenarlo y cómo cargarlo cuando es necesario. En este caso, los objetos deben usarse exclusivamente para transferir los datos y no deben representar ninguna de las lógicas comerciales del sistema.

En realidad, este es más un espectro con estas dos situaciones en cada extremo. Muchos ORM se ubican en el medio, requiriendo que la persistencia sea manejada externamente a la clase, pero a menudo también requiere que algunos metadatos o interfaces se implementen en las clases que se persisten para ayudar con las cosas.

El EF (v1) no admite POCO. Los objetos deben implementar varias interfaces (para proporcionar notificaciones de cambios en los valores de propiedad, etc.) para que el marco pueda persistir. Creo que hay addon frameworks que intentan agregar soporte de POCO al EF, pero no sé qué tan exitosos son. El EF in .net 4.0 tendrá soporte POCO.

POCO a menudo se considera bueno porque permite una fuerte separación de preocupaciones. Puede definir sus objetos de datos para tener un conocimiento absolutamente nulo del mecanismo que se usará para almacenarlos. (Por lo tanto, es más fácil cambiar el mecanismo de almacenamiento por algo diferente en el futuro). También significa que no tiene que diseñar sus objetos de datos con ninguna consideración para la base de datos/marco que se utiliza para almacenarlos.

Answer 2

POCO es simplemente "Objeto CLR sencillo antiguo". Es solo una clase estándar, cualquier clase estándar.

En términos de EF, las personas se refieren a la posibilidad de configurar EF para almacenar sus propias clases (no generadas directamente por EF) en la base de datos.

Answer 3

POCO son clases diseñadas para transferir datos dentro de su aplicación (es decir, mover datos de la capa de datos a la capa ui). También desacoplan la estructura de su aplicación del esquema de su base de datos.

En proyectos pequeños esto no es un gran problema, pero a medida que el proyecto crece, el modelo de objetos (cómo se diseñan sus POCO) tiende a desviarse del esquema de la base de datos.

Otros métodos que se utilizan normalmente en .Net son DataTables y DataSets. Normalmente, los datos se recuperan utilizando el nombre de la columna. Esto une el nombre de columna en su base de datos. Si el nombre de la columna cambia en la base de datos, el código se rompe.

Answer 4

POCO es solo una clase normal, sin interfaces o clases base para que funcione con su capa de base de datos (en este contexto).

Ventajas: 1) no hay dependencias en esa capa de base de datos en particular, por lo que podría cambiarla por una mejor (es decir, NHibernate) sin tener que modificar nada más que la capa de base de datos.

2) hace que resulte más fácil evaluar sus clases por unidades.

3) no hay código de la placa de la caldera para notificar cuando una propiedad ha cambiado, etc. simplemente getters y setters.

Idealmente sus objetos de dominio se cargan desde el ORM, sin que objeto que tiene que tener algo que decir en la forma en que está cargada, ¿cómo se realiza un seguimiento cambios o la forma en que se guarda etc.

NHibernate hace un muy buen trabajo en este , el único requisito es que tenga que hacer que todas las propiedades/métodos sean virtuales, esto es mucho mejor que cualquier dependencia difícil.