In MVC, DAO dovrebbe essere chiamato dal controller o dal modello


14

Ho visto vari argomenti contro il DAO richiamato direttamente dalla classe Controller e anche il DAO dalla classe Model. Personalmente ritengo che se stiamo seguendo il modello MVC, il controller non dovrebbe accoppiarsi con il DAO, ma la classe Model dovrebbe invocare il DAO dall'interno e il controller dovrebbe invocare la classe del modello. Perché, perché possiamo separare la classe del modello da un'applicazione web ed esporre le funzionalità in vari modi come per un servizio REST per usare la nostra classe del modello.

Se scriviamo l'invocazione DAO nel controller, non sarebbe possibile per un servizio REST riutilizzare la funzionalità, giusto? Ho riassunto entrambi gli approcci di seguito.

Approccio n. 1

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

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

    }


 }

Approccio n. 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 -

Ecco cos'è una definizione di modello:

Modello: il modello gestisce il comportamento e i dati del dominio dell'applicazione, risponde alle richieste di informazioni sul suo stato (di solito dalla vista) e risponde alle istruzioni per cambiare stato (di solito dal controller).

Nei sistemi basati su eventi, il modello notifica agli osservatori (in genere visualizzazioni) quando le informazioni cambiano in modo che possano reagire.

Avrei bisogno di un parere di esperti su questo perché ne trovo molti che usano il numero 1 o il numero 2, quindi quale è?


Il controller dovrebbe caricare tutto dal modello e passarlo alla vista.
Jgauffin,

stai suggerendo l'approccio n. 2?

1
"Un controller può inviare comandi alla sua vista associata per modificare la presentazione della vista del modello (ad esempio, scorrendo un documento). Può inviare comandi al modello per aggiornare lo stato del modello (ad esempio, modificare un documento)." .. emm .. dove dice che il controller dovrebbe estrarre i dati o passarli?
Mefisto,

Risposte:


31

Secondo me, devi distinguere tra il modello MVC e l'architettura a 3 livelli. Per riassumere:

Architettura a 3 livelli:

  • dati: dati persistenti;
  • servizio: parte logica dell'applicazione;
  • presentazione: hmi, webservice ...

Il modello MVC si svolge nel livello di presentazione dell'architettura sopra (per una webapp):

  • dati: ...;
  • servizio: ...;
  • presentazione:
    • controller: intercetta la richiesta HTTP e restituisce la risposta HTTP;
    • modello: memorizza i dati da visualizzare / trattare;
    • view: organizza output / display.

Ciclo di vita di un tipico richiesta HTTP:

  1. L'utente invia la richiesta HTTP;
  2. Il controller lo intercetta;
  3. Il controller chiama il servizio appropriato;
  4. Il servizio chiama il dao appropriato, che restituisce alcuni dati persistenti (ad esempio);
  5. Il servizio tratta i dati e li restituisce al responsabile del trattamento;
  6. Il controller memorizza i dati nel modello appropriato e chiama la vista appropriata;
  7. La vista viene istanziata con i dati del modello e restituita come risposta HTTP.

Quello che chiami "ciclo di vita di una tipica richiesta HTTP" non è MVC. E DAO è solo un oggetto, che facilita l'interazione / traduzione tra logica di dominio e persistenza. NON è un nome diverso per il record attivo. Inoltre .. da quando il modello è diventato parte della presentazione ?!
Mefisto,

1
@teresko 1) Sì, è MVC, ma all'interno di un'architettura a 3 livelli. Se no, perché? 2) Avevi ragione, ho modificato. 3) Poiché l'intero modello MVC si svolge nel livello di presentazione. Esempio tipico: Spring MVC, i cui modelli sono solo mappe contenenti coppie chiave-valore. Anche SpringFuse ha fatto questa scelta.
sp00m,

2
Devo essere d'accordo con @ sp00m qui ... La sua descrizione di una tipica richiesta HTTP è accurata per un'app Web MVC e il suo posizionamento del Modello (come la "M" in MVC) come parte del livello di presentazione è anche corretto . Nelle app MVC di livello n, il "Modello" è in genere la facciata del livello di presentazione rispetto al resto dei livelli di seguito.
Eric King,

8

Dal livello del modello.

Per essere più precisi: dai servizi, che sono contenuti nel livello del modello , perché regolano l'interazione tra oggetti di dominio e astrazioni della logica di archiviazione.

Il controller dovrebbe essere responsabile solo della modifica dello stato del livello del modello. I DAO fanno parte del meccanismo di persistenza. Ciò costituisce una parte della logica di business e delle applicazioni del dominio. Se inizi a interagire con DAO nel controller, perdi la logica del dominio nel livello di presentazione .


Per usare un livello di servizio, dovrebbe essere un modello DDD? correggimi se sbaglio. Abbiamo un livello di servizio in MVC?

Puoi avere. I servizi vengono utilizzati per separare la logica del dominio dalla logica dell'applicazione. Ciò diventa necessario, quindi si passa da strutture di dominio CRUD pure (record attivo) a qualcosa che separa la logica di archiviazione dalla logica di dominio. Nel livello di modello completamente realizzato hai 3 separazioni logiche: persistenza, dominio e applicazione.
Mefisto,

3

Non sono sicuro di cosa richieda il modello MVC ufficiale, ma di solito mi piace avere un livello di "servizio" tra i controller e i DAO. Il controller estrae i dati dalla richiesta e li passa alla classe di servizio appropriata. La classe di servizio è responsabile della chiamata di uno o più DAO che restituiscono classi di modello. Tali classi di modelli vengono quindi rimandate al controller per essere inviate al livello vista. L'inserimento del livello di servizio aiuta a riutilizzarlo poiché più controller possono utilizzare gli stessi metodi del livello di servizio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.