W MVC DAO należy wywoływać z kontrolera lub modelu

Widziałem różne argumenty przeciwko bezpośredniemu wywoływaniu DAO z klasy Controller, a także DAO z klasy Model. Faktycznie osobiście uważam, że jeśli podążamy za wzorcem MVC, kontroler nie powinien być sprzężony z DAO, ale z klasą Model powinien wywoływać DAO od wewnątrz, a kontroler powinien wywoływać klasę modelu. Dlaczego, ponieważ możemy oddzielić klasę modelu od aplikacji sieciowej i udostępnić funkcje na różne sposoby, na przykład dla usługi REST, aby korzystać z naszej klasy modeli.

Jeśli napiszemy wywołanie DAO w kontrolerze, usługa REST nie będzie mogła ponownie użyć tej funkcji, prawda? Podsumowałem oba podejścia poniżej.

Podejście nr 1

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

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

    }


 }

Podejście nr 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);

   }

}

Uwaga -

Oto definicja modelu:

Model: Model zarządza zachowaniem i danymi domeny aplikacji, odpowiada na prośby o informacje na temat jej stanu (zwykle z widoku) i odpowiada na instrukcje zmiany stanu (zwykle z kontrolera).

W systemach sterowanych zdarzeniami model powiadamia obserwatorów (zwykle wyświetla) o zmianie informacji, aby mogli zareagować.

Potrzebowałbym opinii eksperta na ten temat, ponieważ wiele osób używa numeru 1 lub 2, więc który to jest?

Moim zdaniem należy rozróżnić wzorzec MVC od architektury trójwarstwowej. Podsumowując:

Architektura 3-poziomowa:

• dane: utrwalone dane;
• usługa: logiczna część aplikacji;
• prezentacja: hmi, serwis internetowy ...

Wzorzec MVC odbywa się w warstwie prezentacji powyższej architektury (dla aplikacji internetowej):

• dane: ...;
• usługa: ...;
• prezentacja:
  • kontroler: przechwytuje żądanie HTTP i zwraca odpowiedź HTTP;
  • model: przechowuje dane do wyświetlenia / przetworzenia;
  • widok: organizuje wyjście / wyświetlanie.

Cykl życia typowego żądania HTTP:

1. Użytkownik wysyła żądanie HTTP;
2. Kontroler przechwytuje go;
3. Kontroler wywołuje odpowiednią usługę;
4. Usługa wywołuje odpowiednie dao, które zwraca niektóre utrwalone dane (na przykład);
5. Usługa traktuje dane i zwraca dane do kontrolera;
6. Kontroler przechowuje dane w odpowiednim modelu i wywołuje odpowiedni widok;
7. Widok jest tworzony z danymi modelu i zwracany jako odpowiedź HTTP.

Z warstwy modelu.

Mówiąc ściślej: z usług zawartych w warstwie modelu , ponieważ zarządzają one interakcją między obiektami domeny i abstrakcjami logiki pamięci.

Kontroler powinien być odpowiedzialny tylko za zmianę stanu warstwy modelu. DAO są częścią mechanizmu trwałości. Stanowi to część logiki biznesowej i logiki aplikacji. Jeśli zaczniesz wchodzić w interakcję z DAO w kontrolerze, przeciekasz logikę domeny w warstwie prezentacji .

Nie jestem pewien, do czego wzywa oficjalny wzorzec MVC, ale zwykle lubię mieć warstwę „usługową” pomiędzy kontrolerami a DAO. Kontroler pobiera dane z żądania i przekazuje je do odpowiedniej klasy usług. Klasa usługi odpowiada za wywołanie jednego lub więcej DAO, które przekazują klasy klasy. Te klasy modeli są następnie wysyłane z powrotem do kontrolera w celu przesłania do warstwy widoku. Włączenie warstwy usług pomaga w ponownym użyciu, ponieważ wiele kontrolerów może korzystać z tych samych metod warstwy usług.