Me pregunto si alguien puede dar una explicación sólida (por ejemplo) de POCO (objeto CLR simple antiguo). Encontré un brief explanation on Wikipedia pero realmente no da una explicación sólida.Explicación de POCO
Busco Pros/Contras, implementación, etc. Beneficio
En lugar de llamarlos de POCO, yo prefiero llamarlos persistencia objetos ignorantes.
Debido a que su trabajo es simple, no necesitan preocuparse sobre para qué se utilizan o cómo se usan.
Personalmente, creo que los POCO son simplemente otra palabra de moda (como Web 2.0, no me explique) en una clase pública con propiedades simples.
Siempre he estado utilizando este tipo de objetos para mantener el estado comercial.
Los beneficios principales de POCO se ven realmente cuando comienzas a usar cosas como el patrón de repositorio, los ORM y la inyección de dependencia.
En otras palabras - se podría crear un ORM (digamos EF), que se aleja de datos desde algún lugar (db, servicio web, etc), entonces proyecto estos datos en objetos (POCO 's).
Estos objetos se pueden pasar más abajo en la pila de aplicaciones a la capa de servicio, y luego al nivel web.
Entonces, si un día decide cambiar a nHibernate, no debería tener que tocar su POCO, lo único que debería cambiarse 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:
Espero que ayude.
Es necesario dar más detalles, tales como el contexto en el que se está planeando utilizar POCO. Pero la idea básica es que creará objetos simples que solo contengan los datos/códigos necesarios. Estos objetos no contendrían ningún "equipaje" como anotaciones, métodos adicionales, clases base, etc. que de otro modo podrían ser requeridos por (por ejemplo) un marco.
Anotaciones, métodos adicionales, clases base son las propiedades básicas del lenguaje C#.Así que no veo ninguna razón para no incluirlos en los objetos POCO ... –
Ejemplo de un Poco:
class Person {
public string FirstName { get; set; }
public string LastName { get; set; }
public string EmailAddress { get; set; }
}
Estoy sorprendido de que esto pueda ser votado - ¿Cómo es la ventaja, la implementación y el beneficio de este profesional? – RPM1984
jaja ... ah bien. Le pasé la "respuesta" @ RPM1984. –
Esto tiene perfecto sentido. Me gusta el uso de la frase "palabra de moda". Parece que ya estoy usando esto en mi proyecto. El uso que estoy haciendo es extraer "algunos" datos de "Usuario" usando L2S (básicamente 4 de los 10 campos en la base de datos) y almacenarlos en un objeto "POCO" muy básico. Luego serializo ese objeto y lo almaceno como el objeto 'UserData' en la cookie de autenticación de ASP.NET. Para que pueda recuperarlo más tarde sin golpear la base de datos de nuevo. –
@rockinthesixstring - exactamente mi punto. hemos estado usando POCO durante años, es solo otra forma de etiquetar algo. Personalmente, me gusta la combinación de patrón de repositorio/inyección de dependencia y ORM: en este caso, sería una locura no usar POCO. Se trata de un acoplamiento flexible. Por supuesto que no tengo idea de qué tecnología estás usando (estoy sacando de mi experiencia con .NET) – RPM1984
Sí, como dije en mi comentario, estoy usando ASP.NET - en realidad estoy usando MVC2. –