Wyjaśnij kontroler widoku modelu

Moje doświadczenie w tworzeniu dynamicznych stron internetowych ogranicza się głównie do serwletów Java. Użyłem Tomcata do opracowania różnych serwletów Java i nie zawahałbym się powiedzieć, że jestem dość biegły w tej technologii, a także w HTML / CSS / JavaScript po stronie klienta dla frontonu.

Kiedy myślę o „dynamicznej witrynie”, myślę: użytkownik żąda adresu URL z ciągiem zapytania, serwer odbiera zapytanie, a następnie dynamicznie generuje kod HTML w celu odpowiedzi na zapytanie. Często wiąże się to z komunikacją z bazą danych w celu pobrania żądanych danych do wyświetlenia. Jest to w zasadzie idea doGetmetody Java HttpServlet.

Ale obecnie coraz częściej słyszę o nowych frameworkach, takich jak Django i Ruby on Rails, z których wszystkie korzystają z architektury „Model View Controller”. Czytałem różne artykuły, które wyjaśniają MVC, ale mam problemy z faktycznym zrozumieniem korzyści. Rozumiem, że ogólną ideą jest oddzielenie logiki biznesowej od logiki interfejsu użytkownika, ale nie rozumiem, jak to naprawdę różni się od normalnego programowania w Internecie. Programowanie sieciowe ze swej natury zmusza cię do oddzielenia logiki biznesowej (programowanie po stronie serwera) od programowania interfejsu użytkownika (HTML lub JavaScript po stronie klienta), ponieważ oba te programy występują w zupełnie innych obszarach programowania.

Pytanie: Co oferuje MVC w stosunku do serwletu Java, a co ważniejsze, czym dokładnie jest MVC i czym różni się od tego, co normalnie robiłbyś w celu opracowania dynamicznej strony internetowej przy użyciu bardziej tradycyjnego podejścia, takiego jak serwlet Java (lub nawet coś starszego jak CGI)? Jeśli to możliwe, wyjaśniając MVC, podaj przykład ilustrujący, w jaki sposób MVC jest stosowany do procesu tworzenia stron internetowych i jak jest on korzystny.

Najpierw myślę, że najlepiej jest mówić o architekturze MVC, a następnie przejść dalej do tego, jak obecnie programujesz.

Architektura MVC jest sposobem na zorganizowanie przepływu pracy w systemie sotfware. Pomyśl o tym jako o warstwowym sposobie implementacji zachowania systemu. Te warstwy to:

1. Model : Reprezentuje Twój model danych, który jest rdzeniem systemu, w którym wszystkie związane z nim informacje powinny być zlokalizowane. Na przykład: jeśli zamierzasz zaprojektować grę, potrzebujesz Graczy, Reguł, Przeszkód i pewnej logiki związanej z interakcjami tych elementów, takich jak: Gracze powinni mieć możliwość sortowania Przeszkód, gdy ma zastosowanie jakiś zestaw Reguł.

   Model jest pierwszym, że należy myśleć off, ponieważ jej będzie w centrum aplikacji .

2. Kontroler : tutaj dzieje się magia i gdzie architektura warstwowa spotyka się z paradygmatem zorientowanym obiektowo, którego zamierzała użyć. Tutaj implementujesz sposób, w jaki system reaguje, gdy użytkownik aplikacji zażąda czegoś na temat aplikacji poprzez interfejs użytkownika.

   Kontroler powinien być w stanie obsługiwać obiekty modelu, wykonywać z nimi operacje, aby osiągnąć to, czego zażądał użytkownik, a następnie przekazać wynik odpowiedniej warstwie widoku, aby renderować go z powrotem do naszego użytkownika.

3. Widok : jest to punkt początkowy i końcowy interakcji użytkownika. Tutaj definiujesz sposób interakcji użytkowników z aplikacją. Obecnie dość często użytkownicy próbują uzyskać dostęp do aplikacji internetowych z różnych rodzajów mediów, takich jak: telefony komórkowe, stoły, komputery osobiste, laptopy itp.

   Zasadniczo każda technologia wymaga innego języka do utworzenia widoku, więc wyobraź sobie, że Twój model danych i sposób, w jaki model współdziała oraz sposób, w jaki renderujesz te interakcje, jest zakodowany na stałe, absolutnie nie ma możliwości ponownego użycia kodu w sposób inny niż CopyPaste . Rezultatem jest kod, który pachnie i mnóstwo czasu zmarnowane na dostosowanie systemu HOLE.

   Virtude posiadania widoku w oddzielnej warstwie pozwala nam pracować niezależnie od modelu, nad którym obecnie pracujemy . Musimy tylko wiedzieć, jak powinniśmy renderować listę obiektów, które kontroler nam wysyła. Jak to wygenerował, jest całkowicie trywialne

W końcu otrzymaliśmy niezależny model, który można dostosować według własnego uznania (zgodnie z naszymi bieżącymi potrzebami (dziś muszę obsługiwać grę Monouser bez żadnych zasad, jutro chcę grać z przyjaciółmi, a teraz z jej Multiuserem itd.) nie zależy to od tego, w jaki sposób udostępnimy to użytkownikowi. Następnie kontroler, który przechwytuje żądania użytkowników pochodzące z widoku, przetwarza obiekty modelu, a następnie przekazuje informacje z powrotem do widoku, aby je renderować.

Wróć do pierwszego zadanego pytania: Jak widzisz (mam nadzieję) MVC to SPOSÓB robienia rzeczy, a nie TECHNOLOGIE do tworzenia oprogramowania. Możesz użyć swoich serwletów Java i zaimplementować w nim MIT Achitecture.

Oto przykładowa strona z pytaniami i odpowiedziami wykorzystująca architekturę MVC, aby trochę wyjaśnić

Odpowiedzieć na Twoje pytanie

What does MVC offer over something like a Java servlet

MVC to wzór, a nie technologia. Tak więc wzorzec można zastosować również podczas programowania za pomocą serwletów.

Pozwól mi spróbować wyjaśnić wzór MVC za pomocą samych serwletów. Tak więc, starając się zastosować MVC, oddziel model (logikę biznesową), widok (logikę prezentacji) i kontroler (serwlet kontrolera, który przekazuje kontrolę do odpowiedniej logiki biznesowej).

W tym przypadku MVC nie polega tylko na oddzieleniu biznesu od warstwy prezentacji i warstwy kontrolera, ale warstwa biznesowa nawet nie wie, że istnieje kontroler lub prezentacja.

Główne frameworki w Javie, takie jak Struts, podążają za tym wzorem. Myślę, że pomyliłeś koncepcję. Możesz przeczytać więcej na ten temat w Internecie.

MVC jest naprawdę łatwy do zrozumienia, to tylko wzorzec projektowy, jednak widziałem, że najtrudniejszym / nadzorowanym jest część Model.

• Model : Twoje dane (nie tylko baza danych !, model może być nawet plikiem ini lub xml albo danymi z usługi internetowej). Klasy modeli służą do definiowania, zestawiania i obsługi danych. Przeczytaj doskonały artykuł zatytułowany „ M w MVC: dlaczego modele są źle rozumiane i niedoceniane ”. Dostęp do modelu powinien mieć wyłącznie kontroler.
• Widoki : Twój kod GUI (prezentacji). Powinien mieć dostęp tylko do kontrolera
• Kontroler : Twoja logika. Obsługuje komunikację między modelem a widokiem.

Koncepcja Model-View-Controller nie jest niczym nowym. Zaczęło się od Smalltalk około 1979 roku.

U podstaw MVC jest sposób organizowania odpowiedzialności za Twój kod, dzięki czemu jest on modułowy, przewidywalny i niezawodny.

Rozdzielenie pozwala na następujące wolności:

• Możliwość ewolucji modelu bez wpływu na logikę aplikacji lub wyświetlanie danych
• Możliwość zmiany logiki biznesowej bez wpływu na model (tj. Dodawania nowych kroków itp.)
• Możliwość reprezentowania modelu na wiele różnych sposobów

Ostrożnie możesz zaprojektować model i kontroler, aby całkowicie zastąpić aplikację komputerową aplikacją internetową jako interfejsem użytkownika.

Niedawno podejście Ruby on Rails do MVC wprowadziło kilka nowszych koncepcji, które zostały skopiowane w prawie wszystkich ramach aplikacji internetowych w stylu MVC. Obejmowało to pojęcia „Konwencja o konfiguracji”, mapowanie działań kontrolera na metody klasowe i kierowanie żądań adresów URL do kodu źródłowego.