Jakie są wady MVC? [Zamknięte]

Używam MVC / MV *, odkąd zacząłem organizować swój kod lata temu. Używam go tak długo, że nie mogę nawet wymyślić żadnego innego sposobu ustrukturyzowania mojego kodu, a każda praca, którą miałem po stażu była oparta na MVC.

Moje pytanie brzmi: jakie są wady MVC? W jakich przypadkach MVC byłby złym wyborem dla projektu i jaki byłby (bardziej) prawidłowy wybór? Kiedy szukam alternatyw MVC, prawie każdy wynik to po prostu różne typy MVC.

Aby zawęzić zakres, aby nie został zamknięty, powiedzmy w przypadku aplikacji internetowych. Pracuję nad backendem i frontendem dla różnych projektów, więc nie mogę powiedzieć tylko frontendu lub backendu.

Zawsze powinieneś pamiętać - MVC jest wzorcem związanym z interfejsem użytkownika. Jeśli budujesz złożoną aplikację, powinieneś zabrać wszystko, co nie jest związane z interfejsem użytkownika, z trojetów MVC do innych klas, podsystemów lub warstw.

To był mój największy błąd. Sporo czasu poświęciłem na zrozumienie tej prostej zasady:

• Nie rozpowszechniaj wzorca MVC wśród całej aplikacji,
• Ogranicz to tylko do rzeczy związanych z interfejsem użytkownika.

Zawsze sprawdzaj, czy kod, który piszesz, jest logicznie w odpowiednim miejscu, co oznacza, że ​​logicznie pasuje do zakresu odpowiedzialności klasy, w której go umieszczasz. Jeśli nie, usuń kod, gdy tylko go zrozumiesz.

Wszystkie wzorce, które nazywacie alternatywami MVC (tj. Model-View-Presenter, Model-View-ViewModel) są tylko sposobem na wdrożenie ogólnej koncepcji MVC.

Moim zdaniem są dwa rodzaje MVC - czyste i nieczyste (z powodu braku lepszego słowa :)

Pure MVC jest tym, co zostało wprowadzone do krótkiej rozmowy:

To było przeznaczone do osobistych aplikacji komputerowych / stacjonarnych. Jak widać, model informuje widoki o wszelkich dokonanych w nim aktualizacjach / zmianach. Nie jest tak w przypadku (nieczystego) MVC.

Innym (nieczystym) MVC reklamowanym w aplikacjach internetowych jest bardziej wzór PAC ( Presentation-abstraction-control ) zamiast klasycznego MVC powyżej. To bardziej organizacja kodu i rozdzielenie problemów:

• Model : Abstrakcja dla przechowywanych danych
• Kontrola : zwykle tak zwana warstwa logiki biznesowej, a także część aplikacji odpowiedzialna za kierowanie żądań HTTP do odpowiedniej logiki biznesowej (inaczej kontrolera)
• Widok : głównie przeglądaj szablony, które formatują dane z modelu i zwracają je klientowi. Model NIGDY nie wysyła aktualizacji do widoku, a widok nie „subskrybuje” aktualizacji z modelu. To byłby koszmar. Dlatego bardziej przypomina PAC niż prawdziwe MVC.

Oto, jak zazwyczaj zbudowana jest aplikacja internetowa:

1. Front-end : MVC na kliencie używającym frameworków jak Backbone.js itp. Jest to w istocie „prawdziwa” forma MVC.
2. Back-end : Znowu masz (nieczyste) MVC / PAC do organizacji kodu i rozdzielania problemów
3. Globalna aplikacja internetowa (dla aplikacji internetowej jako całości): Jeśli masz zaplecze RESTful, które zwraca tylko dane JSON, wówczas cały backend może być postrzegany jako model aplikacji klienckiej frontonu, w której rezydują widok i kontroler.

Jakie są wady MVC ? Ten wzór przetrwał próbę czasu, więc nie ma wielu, które mają tak duże znaczenie, poza tym, że jest trochę „skomplikowane”. Widzisz, MVC jest wzorem złożonym - implementuje wzór strategii / obserwatora i wszystkie są dobrze ułożone, aby utworzyć wzorzec wysokiego poziomu.

Czy powinieneś używać go wszędzie? Może nie. Niezwykle złożone aplikacje internetowe mogą być podzielone na wiele warstw! Użycie tylko warstw Widok / Logika biznesowa / Dane może nie być możliwe. Nadrzędna struktura / organizacja może nadal być podobna do MVC, ale tylko na poziomie makroskopowym.

Oto przykład, w którym sam MVC może być złym wyborem : spróbuj zaprojektować system kontroli ruchu lotniczego lub aplikację do obsługi pożyczek / kredytów hipotecznych dla dużego banku - sam MVC byłby złym wyborem. Nieuchronnie będziesz mieć szyny zdarzeń / kolejki komunikatów wraz z wielowarstwową architekturą z MVC w poszczególnych warstwach i być może nadrzędnym projektem MVC / PAC, aby lepiej zorganizować bazę kodu.

Błędem wielu ludzi przy projektowaniu wzorów jest to, że działa pięknie w jednym miejscu, a następnie próbuje go zastosować wszędzie.

Jeśli pracowałeś przez jakiś czas w jednym miejscu, możesz prawie umawiać się na fragment kodu, sprawdzając, jakie technologie / wzorce projektowe / praktyki były w modzie w tym czasie, np. Singletony / wstrzykiwanie zależności / TDD itp.

Co do tego, gdzie go nie używać. Cóż, wszędzie tam, gdzie jeden element tripletu MVC nie ma zastosowania. Aplikacje konsolowe mogą wcale nie implementować interfejsu. Programy narzędziowe mogą nie mieć modelu. I prawdopodobnie, jeśli nie masz ani modelu, ani widoku, nie potrzebujesz kontrolera.

Problem rzadko dotyczy koncepcji - więcej z implementacją. Bez względu na to, jak dobry jest ten paradygmat, poświęć czas, aby sprawdzić, czy dobrze pasuje do danego problemu.

MVC, jak każdy paradygmat nie integralny z platformą programistyczną, ma większą złożoność. Wadą jest to, że możesz skończyć z oddzielnymi klasami, które nie powinny być oddzielne, i zmniejszać jasność tego, jak ściśle są one powiązane. (Lub, w przypadku trywialnych projektów, nawet zaciemnianie kodu.)

Alternatywą dla pierwszego problemu jest rozdzielenie takiego kodu na niezależne podprojekty; alternatywą dla drugiego jest niepodzielony kod, zarówno w klasie, jak i modelu pliku.

Rozumiem, że stosuję MVC / MV *, kieruję się zasadą Separation of Concerns (SoC) - rozdzielanie programu / kodów na osobne sekcje / części, tak aby każda sekcja mogła rozwiązać osobny problem (zob. Http://en.wikipedia.org / wiki / Separation_of_concerns )

rozdzielenie problemów ma wiele zalet: jedna nie wpłynie na drugą, a programiści mogliby pracować na jednostce bez wpływu na resztę itp. itd. ... MVC nie jest jedynym wzorcem, który następuje po SoC, w zasadzie sam OOP jest świetny pomysł na rozbicie rzeczy na jednostki.

MVC / MV * są bardzo przydatne, gdy zajmujesz się programowaniem związanym z interfejsem użytkownika, podczas gdy poniżej może być więcej wzorów - fabryka, singleton, fasada itp. Większość dużych projektów składa się z wielu warstw obsługujących różne aspekty, ale interfejs użytkownika może nie być konieczny dla niektóre przypadki. Możesz często widzieć MVC - to dlatego, że wiele projektów ma elementy interfejsu użytkownika.

dlatego, mówiąc o wadach MVC, tak naprawdę zależy to od projektów, które wykonujesz - czy ma interfejs użytkownika? czy wymaga dużej skalowalności / rozszerzalności? czy ma wiele interakcji między interfejsem użytkownika a systemem poza systemem? na przykład prosta strona informacyjna wcale nie wymaga MVC, chyba że planujesz w przyszłości rozszerzyć ją na świetną stronę interaktywną.

więc aby ocenić MVC (lub bardziej ogólnie - wzorzec projektowy), daj mu kontekst i zastanów się nad złożonością, skalowalnością, testowalnością, konserwacją, ograniczeniem czasowym itp.