Usando el patrón de repositorio, ¿es mejor guardar los objetos primarios y secundarios juntos o por separado?

Question

Tener un empleado del objeto padre con una lista de direcciones objetos secundarios:

class Employee 
{ 
    List<Address> addresses; 
} 

y un método de repositorio:

void Insert(Employee); 

caso de que el código dentro de este repositorio intento de salvar el Empleado padres, así como la ¿Dirigen los objetos de dirección o deben los repositorios independientes manejar los objetos principales y secundarios?

Si se trata de repositorios separados, al guardar el objeto Employee y sus elementos secundarios dentro del código del cliente, ¿deberían ser llamadas separadas a ese nivel, combinadas en algún tipo de servicio o existe otra alternativa?

Answer 1

El repositorio debe manejar todo el objeto agregado (padre y todos los hijos), porque eso es lo que lo convierte en un repositorio. Si está guardando objetos raíz y secundarios por separado, entonces el patrón que está utilizando realmente no se llama repositorio (aunque podría ser una solución perfectamente buena)

"Repositorio" es simplemente un nombre conveniente para un un patrón de acceso a datos particular que carga y guarda agregados completos de una sola vez, por lo que cuando le dice a otro desarrollador que está usando el patrón de repositorio, saben que eso es lo que está sucediendo.

Answer 2

Intentaré ir con un patrón de unidad de trabajo en el que abra, realice cambios, confirme y, a continuación, se dé cuenta de lo que debe hacer.

Si está en una base de datos relacional, terminará con algo como Hibernate que tiene un asignador por tabla. Si se encuentra en una base de datos no relacional, es posible que deba ser creativo y marcar objetos de dominio como IAggregateRoot o algo así, para saber cuáles tienen sus propios repositorios y cuáles no.

Por ejemplo, si los empleados están almacenados en una SOA y las direcciones en otra, cada uno sería IAggregateRoots, e idealmente la unidad de trabajo entregaría automáticamente cada una de las instancias sucias a su repositorio correspondiente para guardar.

Entonces, su código transparente al cliente, pero no una capa inútil de indirección (como los servicios en su mayoría son, en el mundo java de todos modos, no siempre, pero los que he visto).

Me encanta DDD, pero creo que es un exceso de repositorios y, empíricamente, causa mucha confusión porque las personas siempre preguntan cómo hacerlas correctamente.

A menos que tuviera un sistema con múltiples backends conocidos basados ​​en SOA (y no solo "oye, podríamos ser Amazon algún día y necesitaríamos eso"), me alejaría de los repositorios, personalmente. Los mapeadores/DAOs/algo basados ​​en Hibernate, claro, pero parecen más simples y más concretos que los repositorios.

Answer 3

prefiero un repositorio por mesa, pero unirlos en un repositorio global:

public RootEmployeeRepository (
    IEmployeeRepository employeeRepository, 
    IAddressRepository addressRepository) 
{ 
    // init 
} 

public SaveEmployee (Employee employee) 
{ 
    // call IEmployeeRepository to save the employee record minus childen 
    // call IAddressRepository to save employee.addresses 
    // commit all changes to the DB via UnitOfWork 
} 

Answer 4

prefiero NHibernate que maneja en cascada guarda para usted.

Answer 5

Hay dos tipos de enlaces entre las entidades.

Una es referencia: cuando una entidad contiene una referencia a otro.Que las entidades son independientes y cualquiera de ellas se puede combinar con otra entidad apropiada de ese tipo.

Por ejemplo: cliente y producto, el usuario y la dirección etc.

Otro tipo se aggreagting: cuando pocas entidades representa el objeto único que por algunas razones se almacena en pocas mesas/dividida sobre algunas clases . Pero sigue siendo un objeto solo: una parte no tiene sentido sin otra y no se puede combinar con otra entidad. Una entidad en este caso siempre es principal, y la eliminación de la principal siempre causa la eliminación de entidades agregadas.

Por ejemplo: pedidos y artículos de la orden, la casa y sus habitaciones, etc.

Referencing representa la relación, la agregación representa poseer.

SO Ahorro de la entidad con la referencia no debe guardar entidad referenciada (excepto caso de entidad referenciada es nuevo, pero en este caso se prefiere para salvar entidad referenciada antes).

La entidad de ahorro con agregados debe guardar las entidades agregadas. En una sola transacción. Porque este es un solo objeto. También es preferible no permitir el almacenamiento de agregados por separado (solo si el rendimiento es muy crítico); de lo contrario, podría tener muchos problemas con la concurrencia.