Istnieje około zillionów „frameworków PHP”. I większość z nich uważa się za podążających za wzorem MVC. O ile mile widziane jest przezwyciężenie stylu kodowania osCommerce (logika przetwarzania mocno zmieszana z SQL i HTML), z pewnością istnieją prostsze i łatwiejsze do podążenia podejścia w celu uzyskania możliwego do utrzymania projektu.
Oryginalna koncepcja MVC była ukierunkowana na aplikacje GUI. W przypadku Gtk / Python wydaje się, że można odpowiednio go zastosować. Ale aplikacje internetowe PHP nie działają na widokach na żywo (elementy GUI) i trwałym środowisku wykonawczym Kontrolera. Jest to z pewnością błędne określenie, jeśli opisuje tylko używany kod + grupowanie katalogów lub nazewnictwo klas.
„MVC” wydaje się być używane jako modne hasło do frameworków PHP. I rzeczywiście widziałem, że przyznaje to jedna lub dwie dojrzałe frameworki PHP, ale i tak redefiniuje to wyrażenie, aby pasowało do interny.
Czy to na ogół olej z węża? Dlaczego nie stosuje się lepszej terminologii i propaguje bardziej sensowną koncepcję łatwego w utrzymaniu PHP?
Niektóre szczegółowe rozumowania
Dlaczego podejrzewam, że implementacje PHP nie są zgodne z prawdziwym wzorcem MVC:
Modele : teoretycznie modele powinny być grube i zawierać logikę biznesową, a kontrolery powinny być cienkimi modułami obsługi (wejście-> wyjście). W rzeczywistości frameworki PHP zalecają płytkie modele. CI i Symfony na przykład równają model == ORM. Nawet wejście HTTP jest obsługiwane przez kontroler, nie jest traktowane jako model.
Wyświetlenia : obejścia z AJAX ze zniżką, na stronach internetowych nie może być wyświetleń. Frameworki PHP nadal pompują strony. Interfejs nadal skutecznie podąża za zwykłym modelem HTTP, nie ma przewagi nad aplikacjami innymi niż MVC. (I na koniec, żadna z szeroko rozpowszechnionych struktur php nie może faktycznie wyświetlać w widokach GUI zamiast HTML. Widziałem bibliotekę PHP, która może obsługiwać Gtk / Console / Web, ale nie.)
Kontroler : Nie jestem pewien. Kontrolery prawdopodobnie nie muszą być długo działające i stale aktywne w modelu MVC. W kontekście PHP są to jednak głównie programy obsługi żądań. Nie jest to coś, o co można się kłócić, ale wydaje się to nieco modne.
Czy byłyby lepsze deskryptory? Widziałem rzucane akronimy takie jak PMVC lub HMVC. Chociaż opisy stają się tam bardziej niejednoznaczne, może opisują obecne frameworki mniej hokey?
Odpowiedzi:
Myślę, że patrzysz na to całkowicie niewłaściwie. Aplikacja GUI i strona internetowa to osobne światy, więc dokładnie taka sama definicja MVC nigdy nie zadziała dla obu. W MVC chodzi bardziej o ideał: oddzielenie niektórych części aplikacji, takich jak wyświetlanie i logika.
W PHP (lub ogólnie w Internecie) Widok to sama strona internetowa: wynik HTML. To nie jest „na żywo” zgodnie z twoją definicją, ale po prostu klikasz linki, aby wrócić do kontrolera (tj. Kolejne żądanie strony).
Kontroler i model jest, gdy robi się różnią, tak jak wyjaśniono. W PHP model jest zwykle warstwą danych, oddziaływującą z bazą danych i tak dalej. Ale nadal modeluje sytuację, a kontroler nadal kontroluje przepływ aplikacji, choć tylko raz na ładowanie strony.
Dlatego nazwa „Model-View-Controller” jest całkowicie logiczna, choć inna implementacja w aplikacjach GUI niż aplikacjach internetowych.
źródło
Ponieważ nie jestem świadomy ram PHP, jest to widziane z niskiego poziomu języka.
Modele:
To całkowicie do zrobienia, nie rozumiem, co PHP ma z tym wspólnego ...
Modele to klasy danych w PHP, które prawdopodobnie mogłyby komunikować się z bazą danych,
a następnie można również wysłać ten sam model lub model częściowy w formacie JSON do klienta.
Nie powiedziałbym, że logika biznesowa, to bardziej logika danych (sprawdzanie poprawności, interakcja z bazą danych, import / eksport, ...).
Twoje klasy Kontrolera współdziałają z klasami Modelu, są rzeczywiście cienkie.
Na podstawie danych wyjściowych wykonaj kilka czynności w modelach ... i zwróć ModelView do klienta ...
Nie jestem tak naprawdę świadomy tych frameworków PHP ...
Ale wejście HTTP powinno zostać przetworzone, zanim dotrze do kontrolera,
możesz łatwo stworzyć klasę, która zamienia dane GET i POST w dobry routing i parametry.
Tak właśnie dzieje się w ASP.NET MVC 2 i nie ma w tym nic złego,
nie wiem jak to by się stało z PHP, ale myślę, że byłoby to ściśle powiązane.
Można nawet z łatwością przekształcić dane GET i POST w model, model może zawierać logikę konstruktora. W tym celu można dodać kilka oddzielnych klas.
Wyświetlenia:
Nie rozumiem, dlaczego tak się nie stało, jedyną różnicą jest protokół i PHP może zwrócić JSON itp.
Strona jest twoim widokiem i może żądać i aktualizować przez AJAX + JSON.
Ponownie nie jestem tak naprawdę świadomy tych frameworków PHP, ale w ASP.NET MVC 2 to działa w ten sposób.
Jedyną korzyścią, którą otrzymujesz (i to samo w przypadku zwykłych aplikacji) jest podział na Model (Dane) + Widok (GUI) + Kontroler (Logika). Podobnie, nie zobaczysz frameworka C ++, który może faktycznie wyświetlać dane wyjściowe do HTML lub JSON zamiast widoków GUI.
Kontroler:
MVC to architektura / wzorzec oprogramowania, w którym działa kontroler i jak długo nie działa.
źródło
Nie, na pewno tak!
Pomyśl o aplikacjach AJAX, wtedy widok zapyta o coś do kontrolera i otrzyma częściowy widok z powrotem,
ten widok lub dane są następnie wypełniane gdzieś na stronie, a zatem aktualizowane na bieżąco.
Kontroler jest również trwały, ponieważ możesz używać plików cookie / sesji.
MVC to architektura oprogramowania, niektóre frameworki mogą używać go jako buzz, ale inne robią to poprawnie ...
Zobacz listę niektórych frameworków na Wikipedii .
MVC i SEO to dwie różne rzeczy, ale tak ... MVC zyskuje na popularności.
źródło
Moim zdaniem użycie MVC w php przenosi programistów do sieci. Łatwiej jest przejść z Javy na PHP, jeśli wiesz, jak pracować z MVC.
źródło