No MVC, o DAO deve ser chamado do Controller ou Model


14

Eu vi vários argumentos contra o DAO ser chamado diretamente da classe Controller e também o DAO da classe Model.Infato Pessoalmente, sinto que, se estamos seguindo o padrão MVC, o controlador não deve ser associado ao DAO, mas à classe Model deve invocar o DAO de dentro e o controlador deve invocar a classe de modelo. Por que, podemos dissociar a classe de modelo de um aplicativo da Web e expor as funcionalidades de várias maneiras, como um serviço REST para usar nossa classe de modelo.

Se escrevermos a chamada DAO no controlador, não seria possível para um serviço REST reutilizar a funcionalidade, certo? Resumi as duas abordagens abaixo.

Abordagem # 1

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            new CustomerDAO().save(customer);

    }


 }

Abordagem # 2

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            customer.save(customer);

    }


 }

 public class Customer {

   ...........

   private void save(Customer customer){

        new CustomerDAO().save(customer);

   }

}

Nota -

Aqui está o que é uma definição de Model:

Modelo: O modelo gerencia o comportamento e os dados do domínio do aplicativo, responde a solicitações de informações sobre seu estado (geralmente da exibição) e responde às instruções para alterar o estado (geralmente do controlador).

Em sistemas orientados a eventos, o modelo notifica os observadores (geralmente visualizações) quando as informações são alteradas para que possam reagir.

Eu precisaria de uma opinião de especialistas sobre isso, porque acho que muitos usam o número 1 ou o número 2, então qual é?


1
O controlador deve carregar tudo, desde o modelo e passá-lo para a visualização.
jgauffin

você é a sugestão de abordagem # 2?

1
"Um controlador pode enviar comandos para a visualização associada para alterar a apresentação da visualização do modelo (por exemplo, rolando um documento). Ele pode enviar comandos para o modelo para atualizar o estado do modelo (por exemplo, editar um documento)." .. emm .. onde se diz, esse controlador deve extrair ou distribuir dados?
mefisto 15/11/12

Respostas:


31

Na minha opinião, você precisa distinguir entre o padrão MVC e a arquitetura de três camadas. Resumindo:

Arquitetura de três camadas:

  • dados: dados persistentes;
  • serviço: parte lógica do aplicativo;
  • apresentação: hmi, webservice ...

O padrão MVC ocorre na camada de apresentação da arquitetura acima (para um aplicativo da web):

  • dados: ...;
  • serviço: ...;
  • apresentação:
    • controlador: intercepta a solicitação HTTP e retorna a resposta HTTP;
    • modelo: armazena dados a serem exibidos / tratados;
    • view: organiza a saída / exibição.

Ciclo de vida de uma solicitação HTTP típica :

  1. O usuário envia a solicitação HTTP;
  2. O controlador o intercepta;
  3. O controlador chama o serviço apropriado;
  4. O serviço chama o dao apropriado, que retorna alguns dados persistentes (por exemplo);
  5. O serviço trata os dados e retorna dados ao controlador;
  6. O controlador armazena os dados no modelo apropriado e chama a visualização apropriada;
  7. A visualização é instanciada com os dados do modelo e retornada como a resposta HTTP.

1
O que você chama de "ciclo de vida de uma solicitação HTTP típica" não é MVC. E o DAO é apenas um objeto, que facilita a interação / tradução entre lógica de domínio e persistência. NÃO é um nome diferente para registro ativo. Também .. desde quando o modelo se tornou parte da apresentação ?!
Mefisto

1
@teresko 1) Sim, é MVC, mas dentro de uma arquitetura de três camadas. Se não, por que? 2) Você estava certo, eu editei. 3) Como todo o padrão MVC ocorre na camada de apresentação. Exemplo típico: Spring MVC, cujos modelos são apenas mapas que contêm pares de valores-chave. O SpringFuse também fez essa escolha.
Sp00m

2
Eu tenho que concordar com @ sp00m aqui ... Sua descrição de uma solicitação HTTP típica é precisa para um aplicativo da Web MVC, e seu posicionamento do Modelo (como o 'M' no MVC) como parte da camada de apresentação também está correto . Nos aplicativos MVC de n camadas, o 'Modelo' geralmente é a fachada da camada de apresentação sobre o restante das camadas abaixo.
Eric Rei

8

Da camada do modelo.

Para ser mais preciso: dos serviços, que estão contidos na camada do modelo , porque eles governam a interação entre objetos de domínio e abstrações da lógica de armazenamento.

O controlador deve ser responsável apenas por alterar o estado da camada do modelo. DAOs fazem parte do mecanismo de persistência. Isso constitui uma parte da lógica de negócios e aplicativos do domínio. Se você começar a interagir com DAOs no controlador, estaria vazando a lógica do domínio na camada de apresentação .


Para usar uma camada de serviço, deve ser o padrão DDD? Corrija-me se eu estiver errado. Temos camada de serviço no MVC?

Você pode ter. Os serviços são usados ​​para separar a lógica do domínio da lógica do aplicativo. Isso se torna necessário e você passa das estruturas de domínio CRUD puro (registro ativo) para algo que separa a lógica de armazenamento da lógica de domínio. Na camada de modelo totalmente realizada, você tem 3 separações lógicas: persistência, domínio e aplicativo.
mefisto 15/11/12

3

Não sei ao certo o que o padrão MVC oficial exige, mas normalmente gosto de ter uma camada de "serviço" entre os controladores e os DAOs. O controlador extrai dados da solicitação e os passa para a classe de serviço apropriada. A classe de serviço é responsável por chamar um ou mais DAOs que retornam classes de modelo. Essas classes de modelo são então enviadas de volta ao controlador para serem enviadas para a camada de visualização. A inserção da camada de serviço ajuda na reutilização, pois vários controladores podem usar os mesmos métodos da camada de serviço.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.