Dlaczego powinienem używać wzoru MVC?

Wygląda na to, że każdy, kto obecnie robi aplikacje internetowe, chce używać MVC do wszystkiego. Trudno mi jednak przekonać się do użycia tego wzorca. Rozumiem, że ogólną ideą jest oddzielenie logiki zaplecza od interfejsu użytkownika reprezentującego program. Ogólnie wydaje się, że widoki zawsze zależą do pewnego stopnia od kontrolera, co ostatecznie zależy od modelu. Nie widzę korzyści, jaką daje dodanie kontrolera. Czytałem dużo szumu na temat „w taki sposób należy projektować aplikacje”, ale być może nadal nie rozumiem, co ma gdzie iść. Ilekroć mówię innym o MVC, wydaje się, że każdy ma inne pojęcie o tym, co należy do jakiej kategorii.

Dlaczego więc mam korzystać z MVC? Co zyskuję, używając MVC po prostu oddzielając frontend od logiki backendu? (Większość „zalet”, jakie widzę w tym wzorze, zyskuje się po oddzieleniu interfejsu od implementacji i nie wyjaśniono celu posiadania osobnego „kontrolera”)

Heh Martin Fowler zgadza się z twoim zamieszaniem dotyczącym MVC:

Nie uważam za szczególnie użyteczne myśleć o MVC jako wzorze, ponieważ zawiera on całkiem sporo różnych pomysłów. Różni ludzie czytający o MVC w różnych miejscach biorą z niego różne pomysły i opisują je jako „MVC”. Jeśli to nie spowoduje wystarczającego zamieszania, otrzymasz efekt nieporozumień MVC, które rozwijają się poprzez system chińskich szeptów.

Jednak podaje jedno z bardziej przekonujących wyjaśnień, co motywuje MVC:

Sercem MVC jest to, co nazywam oddzielną prezentacją. Ideą oddzielnej prezentacji jest wyraźny podział między obiektami domenowymi, które modelują nasze postrzeganie świata rzeczywistego, a obiektami prezentacji, które są elementami GUI, które widzimy na ekranie. Obiekty domeny powinny być całkowicie samodzielne i działać bez odniesienia do prezentacji, powinny także być w stanie obsługiwać wiele prezentacji, być może jednocześnie.

Możesz przeczytać cały artykuł Fowlera tutaj .

Wydaje mi się, że zależy to w dużej mierze od problemu, z którym się zmagasz. Widzę podział w następujący sposób:

Model - w jaki sposób reprezentujemy dane? Na przykład, jak przejść z moich obiektów do trwałego magazynu, takiego jak DB -> jak zapisać mój obiekt „User” w bazie danych?

Kontroler - co robię? To jest akcja, która ma miejsce i na poziomie koncepcyjnym należy ją przeprowadzić. Na przykład, przez jakie etapy muszę przejść, aby wystawić fakturę użytkownikowi? Uwaga: może to wpływać na dowolną liczbę obiektów, ale nie wie nic o tym, w jaki sposób są utrwalane w bazie danych.

Zobacz - jak renderować wynik?

Problem, który wydaje mi się, że widzisz, polega na tym, że wiele aplikacji internetowych to uwielbiany interfejs CRUD (Create-Retrieve-Update-Delete) do DB. tzn. kontroler otrzymuje polecenie „dodania użytkownika”, a następnie po prostu mówi modelowi „dodać użytkownika”. Nic nie zyskuje.

Jednak w projektach, w których wykonywane czynności nie dotyczą bezpośrednio zmian w modelu, kontroler znacznie ułatwia życie, a system jest łatwiejszy w utrzymaniu.

Nie powinieneś

Pozwól mi to przeformułować. Powinieneś użyć architektury, która oddziela logikę od twoich widoków. W razie potrzeby powinieneś użyć architektury, która wykorzystuje kontroler (taki jak MVC), jeśli wymagana jest logika, która niekoniecznie pasuje do modelu (np. Analiza drzewa podczas przetwarzania fragmentów adresów URL).

Pochodząc z CI i Yii pomyślałem, że posiadanie dedykowanego kontrolera to naprawdę fajny pomysł. Jednak podczas opracowywania aplikacji z odpowiednimi interfejsami RESTful wydaje się, że kontroler musi obsługiwać logikę nieswoistą dla modelu. Tak więc, przechodząc do Django, a następnie do Pyramid (z których żaden nie jest całkowicie zgodny z architekturą MVC), stwierdziłem, że kontroler nie był tak naprawdę wymaganym komponentem dla aplikacji, które budowałem. Zauważ, że oba frameworki mają funkcje „kontrolujące”, takie jak Dispatching URL w Pyramid, ale jest to kwestia konfiguracji, a nie runtime (np. CController w Yii).

Na koniec dnia naprawdę ważne jest oddzielenie widoku od logiki. Nie tylko oczyszcza to kwestie związane z wdrażaniem, ale także pozwala inżynierom FE / BE pracować równolegle (podczas pracy w środowisku zespołowym).

(Uwaga dodatkowa: nie tworzę aplikacji internetowych profesjonalnie, więc może być coś, czego mi brakuje)

Tak, terminologia na ten temat to bałagan. Trudno o tym mówić, ponieważ nigdy nie do końca rozumiesz, co ktoś rozumie przez te warunki.

Jeśli chodzi o osobny kontroler, powód może zależeć od tego, o której wersji kontrolera mówisz.

Możesz chcieć mieć kontroler, ponieważ po uruchomieniu testów widok zawiera kilka widgetów, których nie napisałeś i prawdopodobnie nie chcesz testować. Tak, oddzieliłeś implementację od dziedziczenia, więc możesz użyć kodu pośredniczącego lub próbnego, aby przetestować inne rzeczy, ale gdy testujesz sam konkretny widok, jest trudniej. Jeśli masz kontroler, który nie ma żadnych widgetów z tym samym kodem, możesz go przetestować bezpośrednio i być może nie musisz testować widgetów za pomocą skryptu.

Inne wersje są dla IMHO trudniejsze do wykazania dla konkretnych korzyści. Myślę, że jest to głównie kwestia oddzielenia problemów - oddzielenie czysto wizualnych problemów z GUI od logiki, która dotyczy GUI, ale nie jest częścią modelu biznesowego (np. Przetłumaczenie aktualizacji z modelu, na który powinny być widoczne widżety). Ale w praktyce te dwie klasy mogą być tak ściśle powiązane (nawet jeśli komunikują się za pośrednictwem interfejsów), że trudno jest nadmiernie się denerwować, łącząc je w jeden widok, i po prostu wypatruj sposobów, w których funkcjonalność może być bardziej przydatna do ponownego użycia gdyby byli podzieleni.

Mówiąc prosto: rozdzielenie obaw. Oprócz całej dyskusji na temat „właściwego” sposobu robienia rzeczy, posiadania czystszego kodu itp. Można po prostu powiedzieć, że MVC pozwala na łatwiejsze ponowne użycie kodu. Zasadniczo programujesz swoje modele i kontrolery i możesz ich używać niewyraźnie w aplikacji internetowej, aplikacji biurowej, usłudze, gdziekolwiek bez większego wysiłku.

Cóż, podstawowy powód korzystania ze struktury MVC pojawia się w konfiguracji przemysłowej, w której pojedynczy proces pracy, jeden model jest wykorzystywany do rozwoju dowolnej aplikacji. Dlatego w przypadku, gdy projekt przechodzi z jednego modułu organizacji do drugiego, o wiele łatwiej jest lepiej zrozumieć scenariusz pracy. Zawiera jasność pracy.
Podczas gdy Ty, jako osoba indywidualna, miałbyś inne podejście do swojego wniosku, ty, pracując w sposób łączony ze współpracownikiem, najpierw omawiałeś i wypracowałeś wspólnie uzgodniony model przez dwoje (ciebie i współpracownika). W takim przypadku oddziela obowiązki przypisane odpowiednio tobie i twojemu współpracownikowi z wyraźnym marginesem.

Myślę, że MVC to tylko modne powiedzenie teoretyków, którzy są menedżerami. Jednak powiedziawszy to, obecna iteracja sieci z dominującym, responsywnym projektem HTML5 i próba stworzenia pojedynczej linii programowania baz danych, która będzie działała w Internecie i na iPhonie, nadaje się do ogólnych pomysłów MVC. Internetowa technologia front-end dosłownie porusza się teraz z prędkością światła dzięki Jquery, nowym iteracjom sterowania CSS, podczas gdy strona serwera rzeczy porusza się w tempie ślimaka.

Ostatecznie wszystko na serwerze będzie po prostu usługami lub „apletami”, które pompują dane do interfejsu użytkownika i w zależności od tego, jakiego masz klienta, dane te będą wykorzystywane i wyświetlane inaczej. W tym sensie MVC ma sens.

Pod tym względem uważam, że w obecnym prawdziwym świecie MVVM jest naprawdę lepszym „wzorcem” lub czymkolwiek, co chcesz to nazwać, niż kontrolerem, ponieważ kontroler zawsze musi wrócić do modelu, aby zmienić widok, a to jest powolne . We wzorze MVVM ViewModel może natychmiastowo aktualizować widok. Ponadto model MVVM promuje zasady projektowania RESTful IMHO.