Can a DAO be called by a Repository?

Navigation
0

Searching and reading information about the main differences of a DAO and a Repository a DAO is based on a table in the database and a Repository returns something that in higher layers is understood (bussiness object) according to this post:   link

Now, suppose we have an Object that inside has 4 objects more each of different tables, would it be valid for a repository to call 4 damage to compose an object like that ?, I do not think that the 4 damages are sent to call the service layer to compose a complex object, all this is born from that I have seen in many books the 3 typical layers of an application:

Controller - > Service - > Repository or Controller - > Service - > DAO

In itself it is only a big doubt if a repository can call damage to compose a more complex object.

An example of a method in the repository would be like this: 

public Cliente obtenerCliente(int idCliente){
    InformacionCliente informacionCliente = 
    daoInformacionCliente.obtenerDatosCliente(idCliente);
    Cuenta cuenta = daoCuenta.obtenerCuenta(idCliente);
    HistoricoCliente historico = daoHistoricoCliente.obtenerHistorialCliente(idCliente);
    Cliente cliente = new Cliente();
    c.setInformacionCliente(informacionCliente);
    c.setCuenta(cuenta);
    c.setHistorial(historico);
    return cliente;
}

I do not know much about architectures, I'm currently reading several DDD books, guided by the domain design, but far from clarifying some things, I get more doubts, in advance thank you very much.

    
asked by user8955532 01.10.2018 в 06:49
source

1 answer

1

Answering your questions: "Suppose we have an Object that inside has 4 objects plus each of different tables, would it be valid for a repository to call 4 damage to compose an object like that?"

It would be necessary to identify what technologies or how you implement your DAO, but if for example you use JPA, which is one of the most used options currently (Spring, Hibernate), the most convenient way is to follow the JPA standards.

That is, to recover for example a "Persona" we have to recover also its "Empresa" , "Coche" , "Direcciones" . In the case of the DAO of "Persona" by default it will automatically recover all the elements, including the objects "Company", "Car", "Addresses" belonging to different tables in BBDD. But for the specific case of "Directions" as it is a list, depending on which implementation of JPA utilities, it is normal that it is Lazy (the list is not brought until you do not need it).

Regarding the architecture of this type of situations, the normal thing is that it is enough with CONTROLLER - > SERVICE - > DAO. Where service is the one that has the ability to call several DAOs.

So the driver will get requests (from the view for example) of the type give me all the "Nominas" of the "Personas" that belong to the "Empresa" X. It is here where the Controller must distinguish that he has to return a payroll list, for which the Payroll Service is called (ex: obtenerNominaParaEmpresa(Empresa e) ), this will perform the corresponding consultation (All people of Company X) calling the DAO of "Person" (ex: findAllByEmpresa(Empresa e) ), but then perform a new search, calling the DAO of "Nomina" (ex: findOneByPersona(Persona p) ), indicating that you want the payroll corresponding to that person (Assuming that PERSON DOES NOT KNOW THE NOMINE).

This would be the simplest way to maintain a maintainable and reusable structure.

For your example of repositirio I would see it in the following way, from the view click on see client information.

The CONTROLLER is directly called to manage this request (getClient), and this will be in charge of managing the request:

CONTROLLER: 

public Cliente obtenerCliente(int idCliente){
//Validaciones, cambios de estados en la vista.. y más logíca
return servicioCliente.obtenerCliente(idCliente);
}

SERVICE: 

public Cliente obtenerCliente(int idCliente){
InformacionCliente informacionCliente = daoInformacionCliente.obtenerDatosCliente(idCliente);
    Cuenta cuenta = daoCuenta.obtenerCuenta(idCliente);
    HistoricoCliente historico = daoHistoricoCliente.obtenerHistorialCliente(idCliente);
    Cliente cliente = new Cliente();
    c.setInformacionCliente(informacionCliente);
    c.setCuenta(cuenta);
    c.setHistorial(historico);
    return cliente;
}

I hope you find it useful.

    
answered by 01.10.2018 в 08:42
Error when displaying Firebase + Vuejs + ElectronJs data Show Text and Hide text