¿Cuál es el beneficio de tener modelos POCO puros?

12

¿Cuál es el mayor beneficio de tener modelos POCO puros? Entiendo que los modelos deben ser limpios y simples, pero tiendo a mantener el mantenimiento de los objetos secundarios dentro de las clases del modelo. Por ejemplo, si tengo ClassA y ClassB definidos de la siguiente manera:

public class ClassA
{
    public string MyProp { get; set; }
    public IEnumerable<ClassB> Children { get; }

    public void AddChild(ClassB newChild) { /*... */ }
    public void RemoveChild(ClassB child) { /* ... */ }
}

public class ClassB
{
    public string SomeProp { get; set; }
} 

¿Hay algún error inherente en tener los métodos de agregar y eliminar? ¿Debería en cambio exponer la lista y permitir que el código del cliente agregue la responsabilidad de las validaciones de datos simples como no nula y no se duplique en otra clase?

Cualquier ayuda es apreciada. Gracias.

    
pregunta Jesse 05.06.2017 - 05:42

3 respuestas

37

Sus dos preguntas no están relacionadas.

  

¿Cuál es el beneficio de tener modelos POCO puros?

Un POCO puro no depende de algún marco empresarial, convención, [] cosa, o está íntimamente conectado a algún objeto que sea similarmente dependiente. En otras palabras, el mundo puede cambiar completamente alrededor de un POCO y simplemente sigue haciendo lo que hace sin preocuparse. No puede romperlo actualizando un marco, moviéndolo a un nuevo sistema o viéndolo divertido. Simplemente sigue trabajando. Las únicas dependencias son las cosas que solicita explícitamente.

POCO no es más que la idea de POJO. La J se cambió a una C porque la gente te ve raro cuando explicas un concepto que tiene Java en su nombre si esas personas usan C #. La idea no depende del lenguaje. Podrían haberlo llamado simplemente Objetos Antiguos. Pero, ¿quién quiere presumir de usar POO?

Dejaré que Fowler explique los orígenes:

  

El término fue acuñado mientras Rebecca Parsons, Josh MacKenzie y yo nos estábamos preparando para una charla en una conferencia en septiembre de 2000. En la charla, señalamos los muchos beneficios de codificar la lógica de negocios en objetos Java regulares en lugar de usar Entity Beans . Nos preguntamos por qué las personas estaban tan en contra del uso de objetos regulares en sus sistemas y llegamos a la conclusión de que era porque los objetos simples carecían de un nombre elegante. Así que les dimos uno, y se prendió muy bien.

     

martinfowler.com: POJO

En cuanto a tu otra pregunta:

  

¿Hay algún error inherente en tener los métodos de agregar y eliminar?

No me gusta que A sepa directamente sobre B . Pero eso es un DIP no una cosa POJO cosa.

    
respondido por el candied_orange 05.06.2017 - 06:44
3

Con Agregar y Quitar, estás implementando Collection<T> de funciones. Pregúntese, ¿por qué usa IEnumerable<T> en lugar de List<T> o alguna otra clase mutable? Aparentemente no es porque su colección debería ser de solo lectura.

La única razón por la que puedo pensar es que desea controlar qué métodos de acceso desea publicar. En ese caso, sería mejor crear su propia clase de colección, encapsular una lista, implementar sus métodos de selección Agregar y quitar e implementar IEnumerable<T> . Luego, use eso en lugar de IEnumerable<T> para el tipo de su colección secundaria.

Pero me parece que List<ClassB> probablemente te sirva bien.

    
respondido por el Martin Maat 05.06.2017 - 09:00
0

¿A qué se agrega AddChild y RemoveChild ? Si es de la base de datos (o almacén de persistencia de cualquier tipo), tiene un registro activo. No siempre es necesariamente algo malo, pero definitivamente te acerca a tener que preocuparte por los marcos, las convenciones, las dependencias, etc., como menciona @CandiedOrange.

Al mismo tiempo, ¿cuál sería el punto de evitar una dependencia de ClassA a ClassB (o al menos InterfaceB) si todos están en la misma aplicación? En el dominio del mundo real que tu aplicación está modelando, las cosas dependen unas de otras. Los objetos del mundo real do tienen colecciones de otros objetos que "pertenecen" a ellos. Es totalmente apropiado representar esas relaciones en su código.

La única razón por la que se complica un poco es porque parece que tiene la necesidad de administrar exactamente cómo un ClassB se asocia y se aleja de ClassA. Así que tienes un poco de comportamiento para implementar. Puede implementarlo dentro de la clase (que es totalmente "legal"; consulte enlace ), o puede tener algún tipo de clase separada que contiene ese comportamiento. Haga lo que tenga más sentido para sus circunstancias individuales.

En cualquier caso, POJO / POCO es en realidad solo POO como se suponía, sin adornos y sin compromiso. Sigue los principios de OOP y estarás a salvo.

    
respondido por el John M Gant 05.06.2017 - 17:10

Lea otras preguntas en las etiquetas