¿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.
Si alguna vez ha lidiado con el dolor de cabeza de las clases de ActiveRecord con cientos de métodos que pueden o no ser lo que desea en un momento dado, creo que sería más fácil entender la apelación.
—
Casey
La razón principal para evitar este diseño en particular es porque va en contra de las pautas de diseño de .net. Es completamente arbitrario, pero la gente espera que la colección tenga los métodos de mutación.
—
Frank Hileman
@Casey No estoy usando el patrón Active Record, el método de agregar simplemente está haciendo una validación de datos menor. El método remove está ahí porque la colección no está expuesta, simplemente agregan y eliminan de una lista interna. Sin embargo, lo he cambiado para usar un tipo de colección diferente que me permite hacer la validación mientras sigo usando los métodos incorporados Agregar / Eliminar.
—
Jesse
AddChild(ClassB newChild) => Children.Add(newChild ?? new NullClassB())