Czy MVC to tylko SEO programowania PHP?


9

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?


Podsumowując: frameworki PHP implementują koncepcję podobną do oryginalnej MVC. Myślę, że najlepiej go przybić tutaj: stackoverflow.com/questions/1549857/simple-php-mvc-framework/…
mario

Zaskoczyło mnie, że „większość frameworków PHP używa widoków jako zwykłych stron”. We wszystkich frameworkach PHP, z których korzystałem, Widok może być wszystkim, jest to po prostu szablon HTML. Może to być pole tekstowe, pasek boczny, pasek nawigacji, blok statycznego tekstu, a nawet układ strony. Nie mogę wymyślić żadnej struktury, która nie pozwala osadzać widoków w widokach, pozwalając ci robić praktycznie wszystko, o ile twoja logika / przetwarzanie biznesowe jest wcześniej wykonywane w kontrolerze.
Lotus Notes

Modelu (nie mnogą) jest warstwa . To nie jest pojedynczy plik lub klasa. Jest to zbiór obiektów domeny, maperów danych i usług. Przeczytaj to .
James

3
... SEO? "Optymalizacja wyszukiwarki"?
Izkata

Odpowiedzi:


12

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.


Nie mam kłótni z abstrakcyjną koncepcją MVC. Nie zgadzam się z tym, że frameworki PHP są nieuczciwe w rzeczywistości, jeśli chodzi o implementację Passive-MVC. Nawet wzorzec „Model-View-Presenter” jest bardziej realistycznym opisem. Ale oczywiście, warunki muszą zostać zgięte, gdy zastosujesz je do innej domeny. Pierwotne pytanie; czy termin gięcie może uczynić z niego modne słowo?
mario

3

Ponieważ nie jestem świadomy ram PHP, jest to widziane z niskiego poziomu języka.

Modele:

teoretycznie modele powinny być grube i zawierać logikę biznesową

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, ...).

a kontrolery powinny być cienkimi modułami obsługi (wejście-> wyjście)

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 ...

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.

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:

obejścia ze zniżkami AJAX, na stronach internetowych nie może być wyświetleń. Frameworki PHP nadal pompują strony.

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.

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.)

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:

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.

MVC to architektura / wzorzec oprogramowania, w którym działa kontroler i jak długo nie działa.


1

Ale aplikacje internetowe PHP nie działają na widokach na żywo (elementy GUI) i trwałym środowisku wykonawczym Kontrolera.

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” wydaje się być używane jako modne hasło do frameworków PHP.

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 .

czy MVC to tylko SEO programowania php?

MVC i SEO to dwie różne rzeczy, ale tak ... MVC zyskuje na popularności.


1
Jasne, elementy interfejsu użytkownika AJAX przybliżają go, ale jest to obiektywnie obejście. I nadal wydaje się to zginać definicję. (Przy okazji, wiem o Cappucino.org i innych prawdziwych zestawach narzędzi, ale odwoływałem się do dużych frameworków PHP).
mario

Nie nazwałby tego obejściem, równie dobrze możesz liczyć Qt i inne frameworki jako obejścia również wtedy ... Istnieje tylko narzut transferu danych między serwerem a klientem, a przy obecnych prędkościach połączeń i opóźnieniach nie jest to nawet dużo już. Nie widzę, jak to zgina definicję: wzorzec izoluje logikę domeny (logikę aplikacji dla użytkownika) od danych wejściowych i prezentacji (UI), pozwalając na niezależne tworzenie, testowanie i utrzymanie każdego z nich.
Tamara Wijsman,

1
Rozumiem, co masz na myśli. Jeśli interpretujesz PHP jako serwer aplikacji, a AJAX jako mechanizm RPC między logiką a interfejsem użytkownika, tak. Jednak nadal nazwałbym to obejściem HTTP. OTOH nie jest pewien, czy ma to znaczenie dla nazwy MVC. Myślę, że tak naprawdę sprzeciwiam się temu, że tylko „MVC” „” zapewnia responsywne i interaktywne interfejsy sieciowe, które opisujesz.
mario

-1

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.


+1 Ale czy jest to tylko zaleta terminologiczna, czy też istnieją struktury PHP zbliżone do implementacji Java. (I domyślnie mówisz o GUI Java lub Web / Struts?)
mario

Nie wiem dokładnie, ale używam frameworka Zend i wydaje mi się, że jest tak samo w przypadku innych frameworków MVC: bardzo ważne jest, aby wiedzieć, co robić w swoim modelu, widoku i kontrolerze, a więc przepaść między światem programowania a skryptami internetscripting świat jest zamknięty. Być może wiek pisania skryptów dobiegł końca i bardzo bym tego chciał. To zbyt buggy.
baklap
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.