¿Cuál es el principal beneficio de tener modelos POCO puros? Entiendo que los Modelos deben ser limpios y simples, pero me gusta mantener el mantenimiento de los objetos secundarios dentro de las clases de modelos. Por ejemplo si tengo un ClassAy ClassBdefinido 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 algo inherentemente malo en tener los métodos de agregar y quitar? ¿Debería simplemente exponer la lista y permitir que el código del cliente agregue lo que pase la responsabilidad de validaciones de datos simples como no nulo y no duplicar a otra clase?
Cualquier ayuda es apreciada. Gracias.
AddChild(ClassB newChild) => Children.Add(newChild ?? new NullClassB())Respuestas:
Sus dos preguntas no están relacionadas.
Un POCO puro no depende de algún marco empresarial, convención, [] cosita, o está íntimamente conectado a algún objeto que sea igualmente dependiente. En otras palabras, el mundo puede cambiar completamente alrededor de un POCO y simplemente sigue haciendo lo que hace sin importarle. No puede romperlo actualizando un marco, moviéndolo a un nuevo sistema o viéndolo divertido. Simplemente sigue funcionando. Las únicas dependencias son las cosas que pide explícitamente.
POCO no es más que la idea de POJO. La J se cambió a una C porque las personas te miran divertido 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 simples. ¿Pero quién quiere presumir de usar POO?
Dejaré que Fowler explique los orígenes:
En cuanto a su otra pregunta:
No me gusta
Asaberlo directamenteB. Pero eso es una cosa DIP , no una cosa POJO .fuente
Bpor simplicidad, idealmente ambos implementarían interfaces. PeroAaún tiene una lista deIInterfaceB. ¿Hay algún problema con elAddChildmétodo si los elementos secundarios se acoplan libremente mediante referencias de interfaz?Con Agregar y quitar, está implementando
Collection<T>características. Pregúntese por qué está utilizando enIEnumerable<T>lugar deList<T>o alguna otra clase mutable? Aparentemente no es porque su colección sea 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 Eliminar e implementar
IEnumerable<T>. Luego use eso en lugar deIEnumerable<T>para el tipo de colección de sus hijos.Pero me parece
List<ClassB>que probablemente solo te sirva bien.fuente
¿Qué
AddChildagrega yRemoveChildquita de? Si es de la base de datos (o del almacén de persistencia de cualquier tipo), tienes 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 modela su aplicación, las cosas dependen unas de otras. Objetos del mundo real lo tienen colecciones de otros objetos que "pertenecen" a ellos. Es completamente apropiado representar esas relaciones en su código.
La única razón por la que se vuelve incluso un poco complicado es porque parece que tiene la necesidad de administrar exactamente cómo un ClassB se asocia y se disocia de ClassA. Entonces tienes un pequeño comportamiento para implementar. Puede implementarlo dentro de la clase (que es totalmente "legal"; consulte /programming//a/725365/44586 ), o puede tener algún tipo de clase separada que contenga ese comportamiento. Haga lo que tenga más sentido para sus circunstancias individuales.
En cualquier caso, POJO / POCO es realmente solo POO como debe ser, sin adornos y sin gravámenes. Siga los principios de OOP y estará a salvo.
fuente