Wzorzec MVC. Pytania

0

Witam
Do końca nie rozumiem powyższego wzorca w związku z tym mam kilka pytań.
Czy konfiguracja [model - view - controller] to jest jednoznaczne odwzorowanie
na 3 klasy czy może być tak że np widok pobiera dane do wyswietlania z kilku klas lub
kontroler pobiera dane z kilku widoków (nie wiem jakie są liczności miedzy tymi klasami)?
Czy kontrolerów może byc wiele czy jeden na całą aplikacje? Np w C++ tworząc program obiektowy funkcja
main jest takim jakby kontrolerem, który tworzy obiekty i kontroluję na ich podstawie
zachowanie całej aplikacji i nie wiem jakie mialo by zastosowanie tworzenie wielu
kontrolerow?

1

strasznie pokreciles
https://www.codecademy.com/articles/mvc

w wielkim skrocie
view -> wyswietla dane
model -> zawiera czyste dane (bez logiki)
controller -> bierze dane z modelu, przetwarza je i wysyla do view zeby on je sobie jakos wyswietlil. Controller jest zawsze pomiedzy view a modelem

0

Ok dzieki za link.
A to nie jest tak, że widok sam pobierze dane w celu wyświetlenia
i nie potrzebuje do tego celu kontrolera?


3

Ten wzorzec jest właśnie po to, żeby to sensownie rozdzielic - widok ma zajmować się prezentacją otrzymanych "z góry" (czyli od kontrolera) danych, a nie ich pobieraniem z bazy.

4
fasadin napisał(a):

view -> wyswietla dane
model -> zawiera czyste dane (bez logiki)
controller -> bierze dane z modelu, przetwarza je i wysyla do view zeby on je sobie jakos wyswietlil. Controller jest zawsze pomiedzy view a modelem

Sam coś pokręciłeś:
View wyświetla i nie zawiera logiki
Model zawiera dane do wyświetlenia w View, jeśli bawimy się w MVVM to ViewModel zawiera prostą logikę, żeby view nie musiało w żaden sposób obrabiać danych
Controller - bierze dane z serwisów (ewentualnie z klientów webserwisów), a nie z modeli. Modele są tylko kontenerami danych, ich źródłem są serwisy. Kontroler nie przetwarza danych.

Czyli View <--ViewModel-- Controller <--Model-- Service.

5

W MVC czy MVP nie ma takiego pojęcia jak "serwisy". Model zawiera właśnie logikę aplikacji i do tej kategorii wchodzą serwisy a także klasy domenowe.

0

Czyli generalnie chodzi o podzial aplikacji na 3 czesci. Teraz programuje troche w Javie EE i mam tam servlety(kontrolery) pliki .jsp (widoki) i jakies klasy .java , ktore
tworza model. Rozumiem to tak, że w pliku .jsp aby wypisac cos pobieram dane z modelu np <%=Klient.getImie() %> czyli widok bezposrednio pobiera dane z modelu bez kontrolera. A jezeli np uzytkownik wypelni jakis formularz to idzie to do servletu i on zajmuje sie wtedy operacjami na modelu. @Shalom , mogłbys wyjasnic czym sie roznia i o co chodzi z serwisami i klasami domenowymi w kontekscie tych wzorcow MV*

0

Bylem Czarnym Samcem ;p

5
Biały Orzeł napisał(a):

o co chodzi z serwisami i klasami domenowymi w kontekscie tych wzorcow MV*

Chodzi o to, że model to nie jest żadne POJO/POCO/DTO, czy inna struktura danych. Model to warstwa/warstwy, nie klasa.

Model można implementować np. za pomocą prostych struktur danych i wzorca transaction script, który na nich operuje, można też stosując DDD, wraz z jego tworami jak encje i serwisy domenowe. Chodzi o to, że Model samodzielnie realizuje to, co robi aplikacja, można podać mu wejście, a on zwróci prawidłowe wyjście. Nie ma np. logiki biznesowej w kontrolerach, jak to uważa spora część ludzi, która za źródło wiedzy o wzorcach projektowych uważa tutoriale. Model też nie jest też źródłem danych do wyświetlenia.

Steve Burbeck, Ph.D. napisał(a)

In the MVC paradigm the user input, the modeling of the external world, and the visual
feedback to the user are explicitly separated and handled by three types of object, each
specialized for its task. The view manages the graphical and/or textual output to the
portion of the bitmapped display that is allocated to its application. The controller
interprets the mouse and keyboard inputs from the user, commanding the model and/or the
view to change as appropriate. Finally, the model manages the behavior and data of the
application domain, responds to requests for information about its state (usually from the
view), and responds to instructions to change state (usually from the controller).

0

To jak w końcu to wygląda, bo co post każdy inaczej pisze.

2

Tak jak napisali @somekind i @shalom.

2

Ja dzielę tak:

  • Widok to to co użytkownik widzi, zero logiki, najbardziej zaawansowana jaka jest dostępna w widoku to translacje. Zero ifów, pętli, etc. Po to są Presenters.
  • Kontroler to to na co użytkownik wpływa: obsługa zapytań, kliknięć, ruchów myszą, cokolwiek. To jest jedyne miejsce, gdzie użytkownik ma wpływ na cokolwiek.
  • Model - cała reszta zawierająca logikę, tutaj mamy kolejne podziały:
  • Repozytoria
  • Dane
  • Serwisy
  • Prezenterów
  • etc.
0

Zrozumiałem temat, dzięki za odpowiedzi.

1 użytkowników online, w tym zalogowanych: 0, gości: 1