C# business objects and collections

Question

Tengo dificultades para entender los objetos comerciales o, más específicamente, las colecciones de objetos comerciales.

Aquí hay un ejemplo rápido de lo que estoy tratando de hacer.

Si tengo un Objeto de incidente, este objeto puede tener varias personas involucradas y cada uno de esos objetos Persona puede tener varias notas. Las notas no pueden existir sin un objeto Persona y los objetos Persona no pueden existir sin un Objeto de incidente.

Si tengo la Lista pública < Nota> notes = new List < Nota>() entonces los métodos como ADD y REMOVE están disponibles para Person in Incident. Supongo que si llamara a esos métodos en la colección de Notes, simplemente lo eliminará de la lista pero no ejecutará ningún código para agregar/actualizar/eliminar realmente al empleado de la fuente de datos. Esto me lleva a creer que no debería usar List sino algo más.

Esto también me lleva a otra pregunta. Donde deberían residir las operaciones reales de la base de datos CRUD. ¿Debería un objeto Note tener su propio CRUD o debería el objeto Person ser responsable de él, ya que no puede existir sin él?

Estoy un poco perdido sobre qué camino tomar y me gustaría obtener esta parte correcta porque será la plantilla para el resto del programa.

Answer 1

una gran información ha sido dada, pero una cosa que usted ha mencionado que le pueden estar confuso es la siguiente:

"Si tengo Lista Pública señala = new lista() a continuación métodos tales como ADD, QUITAR estará disponible para la persona dentro del incidente. "

Todo depende de cómo diseñe sus clases. Una cosa en la que debes pensar es la forma en que estos datos se relacionan entre sí. Eso te ayudará a imaginarte el diseño de tu clase.

suena como la siguiente:

• Un incidente puede implicar muchas personas
• Una persona puede crear muchas notas
• Una nota es el nivel más bajo y existe debido a un incidente que se está creando y una persona (s) responsable (s) trabajando en ese incidente.

Incidente 1 - muchas personas

Persona 1 - muchas notas

Usted puede hacer este tipo de relación en un número de maneras. Una forma puede ser separar los objetos involucrados y luego crear objetos unidos.

Por ejemplo

public class Incident { 
//insert incident fields here 
//do not add person logic/notes logic 
//probably contains only properties 
} 

public class Person { 
//insert person fields 
//private members with public properties 
//do not embed any other logic 
} 

public class Comment { 
//insert comment private fields 
//add public properties 
//follow the law of demeter 
} 

Estas clases no dan detalles entre sí, que son sólo repositorios para almacenar esta información. A continuación, se relacionan estas clases entre sí, por ejemplo,

public class IncidentPersonnel { 
List<Person> p; 
//add methods to add a person to an incident 
//add methods to remove a person from an incident 
.... 
} 

entonces puede que tenga otra clase de manejo de la comentando por personal

public class PersonnelNotes { 
List<Note> n; 
//other methods... 
} 

Usted puede ir más allá con esto, pero puede complicar las cosas, pero estoy solo dándote otra idea de cómo manejar esto.

tratar de seguir the law of demeter for functions

Encapsular todos sus objetos, además, su vecino puede hablar con usted, pero no mucho más ... Esto ayudará a mantener las clases de acoplamiento flexible y hace que el proceso de pensamiento un poco más simple para ti.

Finalmente mencionó cómo deberían funcionar las operaciones CRUD. Todo esto vuelve a su DAL (Capa de acceso a datos). En lugar de devolver filas de datos de una tabla, puede devolver un objeto referenciado con todos sus atributos. Añade y elimina el trabajo de la misma manera (pasando o entrando un objeto). Puede usar un ORM o escribir su propio DAL. Todo depende de qué tan involucrado quieras involucrarte :).

Answer 2

Tiene varias preguntas diferentes en una aquí, intentaré responder la mayoría.

En cuanto a los problemas que utilizan List<T> - el marco tiene un ReadOnlyCollection<T> que es útil en exactamente su situación. Esta es una colección que no permite agregar o eliminar una vez creada.

En cuanto a la responsabilidad de la operación CRUD, que debería pertenecer a su capa de datos, no a ninguno de sus objetos (consulte SRP - Principio de responsabilidad única).

Answer 3

La manera en que lo hago es: cada objeto que tiene objetos secundarios contiene una lista de ellos, y cada objeto con un elemento primario contiene una propiedad con su tipo. La adición se realiza rellenando un objeto (o una jerarquía de objetos) y enviando al DAL para persistencia si así lo desea. Las operaciones CRUD están todas en el DAL, que es independiente de los tipos de objeto, pero utiliza dichos tipos para determinar a qué tablas, columnas, etc. acceder. Eliminar es lo único que se soluciona de manera diferente al establecer la propiedad Eliminada de un objeto que activa el DAL para eliminarlo.

Ahora con respecto a la lógica de negocio - lo hace no residen con los objetos mismos (los DAO) sino que se lleva a cabo por las clases que reciben o se reúnen tales DAOs cuando sea necesario, lleve a cabo su trabajo y enviar el DAOs de nuevo a la DAL para actualizaciones