Wróćmy do implementacji MVC. Porównanie routingu opartego na konwencji i routingu opartego na atrybutach

Wiele osób zaczyna pisać projekt do pracy z jednym zadaniem, nie sugerując, że może on rozwinąć się w system zarządzania wieloma użytkownikami, na przykład treścią lub, nie daj Boże, produkcją. I wszystko wydaje się świetne i fajne, wszystko działa, dopóki nie zaczniesz rozumieć, że napisany kod składa się wyłącznie z kul i twardego kodu. Kod jest pomieszany z układem, zapytaniami i kulami, czasem wręcz nieczytelny. Powstaje palący problem: dodając nowe funkcje, trzeba bardzo długo majstrować przy tym kodzie, pamiętając „co tam napisano?” i przeklnij siebie w przeszłości.

Być może słyszałeś nawet o wzorcach projektowych, a nawet przeglądałeś te wspaniałe książki:

E. Gamma, R. Helm, R. Johnson, J. Vlissides „Techniki projektowania obiektowego. Wzorce projektowe";
M. Fowler „Architektura aplikacji dla przedsiębiorstw”.

Wielu, nie zrażonych ogromnymi podręcznikami i dokumentacją, próbowało przestudiować którykolwiek ze współczesnych frameworków i w obliczu złożoności zrozumienia (ze względu na obecność wielu koncepcji architektonicznych sprytnie ze sobą powiązanych) odłożyło studiowanie i wykorzystanie nowoczesne narzędzia „na drugim planie”.

Artykuł ten przyda się przede wszystkim początkującym. W każdym razie mam nadzieję, że za kilka godzin będziesz mógł zorientować się w implementacji wzorca MVC, który leży u podstaw wszystkich nowoczesnych frameworków internetowych, a także zdobędziesz „pożywienie” do dalszej refleksji na temat „jak to zrobić Zrób to." Na końcu artykułu znajduje się wybór przydatnych linków, które pomogą Ci również zrozumieć, z czego składają się frameworki internetowe (oprócz MVC) i jak działają.

Doświadczeni programiści PHP raczej nie znajdą w tym artykule nic nowego dla siebie, ale ich komentarze i komentarze do tekstu głównego będą bardzo pomocne! Ponieważ Bez teorii praktyka jest niemożliwa, a bez praktyki teoria jest bezużyteczna, potem najpierw będzie trochę teorii, a potem przejdziemy do praktyki. Jeśli już zapoznałeś się z Koncepcja MVC, możesz pominąć część teoretyczną i przejść od razu do praktyki.

1. Teoria Wzorzec MVC opisuje prosty sposób konstruowania aplikacji, którego celem jest oddzielenie logiki biznesowej od interfejsu użytkownika. Dzięki temu aplikację łatwiej jest skalować, testować, utrzymywać i oczywiście wdrażać.

Przyjrzyjmy się diagramowi koncepcyjnemu wzorca MVC (moim zdaniem jest to najbardziej udany diagram, jaki widziałem):

W architekturze MVC model udostępnia dane i reguły logiki biznesowej, za które odpowiada widok interfejs użytkownika, a kontroler zapewnia interakcję pomiędzy modelem i widokiem.

Typowy przepływ aplikacji MVC można opisać w następujący sposób:

Gdy użytkownik odwiedza zasób sieciowy, skrypt inicjujący tworzy instancję aplikacji i uruchamia ją do wykonania.
To wyświetla widok, powiedzmy strona główna strona.

Aplikacja odbiera żądanie od użytkownika i określa żądany kontroler oraz akcję. W przypadku strony głównej wykonywana jest akcja domyślna ( indeks).

Aplikacja tworzy instancję kontrolera i uruchamia metodę akcji,
który zawiera na przykład wywołania modelu odczytujące informacje z bazy danych.

Następnie akcja tworzy widok z danymi uzyskanymi z modelu i wyświetla wynik użytkownikowi.

Model - zawiera logikę biznesową aplikacji i zawiera metody pobierania (mogą to być metody ORM), przetwarzania (na przykład reguły walidacji) i dostarczania określonych danych, przez co często jest bardzo gruby, co jest całkiem normalne.
Model nie powinien bezpośrednio wchodzić w interakcję z użytkownikiem. Wszystkie zmienne związane z żądaniem użytkownika muszą zostać przetworzone w kontrolerze.
Model nie powinien generować kodu HTML ani innego kodu wyświetlacza, który może zmieniać się w zależności od potrzeb użytkownika. Taki kod powinien być przetwarzany w widokach.
Ten sam model, np. model uwierzytelniania użytkownika, można zastosować zarówno w części użytkownika, jak i części administracyjnej aplikacji. W takim przypadku możesz umieścić ogólny kod osobna klasa i dziedziczyć po nim, definiując metody specyficzne dla podaplikacji w jej potomkach.

Widok - służy do określenia zewnętrznego wyświetlania danych otrzymanych ze sterownika i modelu.
Widoki zawierają znaczniki HTML i małe wstawki kodu PHP do przeglądania, formatowania i wyświetlania danych.
Nie powinien mieć bezpośredniego dostępu do bazy danych. To właśnie powinny robić modelki.
Nie powinno działać z danymi uzyskanymi na żądanie użytkownika. To zadanie musi wykonać kontroler.
Może bezpośrednio uzyskać dostęp do właściwości i metod kontrolera lub modeli w celu uzyskania danych wyjściowych.
Widoki są zwykle podzielone na wspólny szablon, zawierający znaczniki wspólne dla wszystkich stron (na przykład nagłówek i stopkę) oraz części szablonu, które służą do wyświetlania danych wyjściowych z modelu lub wyświetlania formularzy wprowadzania danych.

Kontroler to klej, który łączy modele, widoki i inne komponenty działająca aplikacja. Administrator odpowiada za przetwarzanie żądań użytkowników. Kontroler nie powinien zawierać zapytań SQL. Lepiej trzymać je w modelach. Kontroler nie powinien zawierać kodu HTML ani innych znaczników. Warto mieć to na uwadze.
W dobrze zaprojektowanej aplikacji MVC kontrolery są zwykle bardzo cienkie i zawierają tylko kilkadziesiąt linii kodu. Czego nie można powiedzieć o Stupid Fat Controllers (SFC) w CMS Joomla. Logika kontrolera jest dość typowa i w większości przeniesiona do klas bazowych.
Modele natomiast są bardzo grube i zawierają większość kodu związanego z przetwarzaniem danych, ponieważ struktura danych i zawarta w nich logika biznesowa są zwykle dość specyficzne dla konkretnej aplikacji.

1.1. Kontroler frontu i kontroler strony W większości przypadków interakcja użytkownika z aplikacją internetową odbywa się poprzez klikanie łączy. Spójrz teraz na pasek adresu swojej przeglądarki - otrzymałeś ten tekst z tego linku. Inne linki, takie jak te po prawej stronie tej strony, dadzą Ci inną treść. Zatem łącze reprezentuje konkretne polecenie do aplikacji internetowej.

Mam nadzieję, że już zauważyłeś, że różne witryny mogą mieć idealne różne formaty budowa pasek adresu. Każdy format może wyświetlać architekturę aplikacji internetowej. Chociaż nie zawsze tak jest, w większości przypadków jest to oczywisty fakt.

Rozważmy dwie opcje paska adresu, które wyświetlają tekst i profil użytkownika.

Pierwsza opcja:

www.example.com/article.php?id=3

www.example.com/user.php?id=4

Tutaj każdy skrypt jest odpowiedzialny za wykonanie określonego polecenia.

Druga opcja:

www.example.com/index.php?article=3

www.example.com/index.php?user=4

I tutaj wszystkie wywołania występują w jednym skrypcie Index.php.

Podejście wielopunktowe można zobaczyć na forach phpBB. Forum przegląda się za pomocą skryptu viewforum.php, tematy przegląda się za pomocą viewtopic.php itp. Drugie podejście, dostępne poprzez pojedynczy fizyczny plik skryptu, można zobaczyć w moim ulubionym CMS MODX, gdzie wszystkie wywołania przechodzą przez plik Index.php.

Te dwa podejścia są zupełnie różne. Pierwsze jest typowe dla wzorca Kontroler Strony, natomiast drugie podejście jest implementowane przez wzorzec Kontroler Frontu. Kontroler strony jest dobry dla witryn o dość prostej logice. Z kolei kontroler żądań konsoliduje wszystkie czynności związane z przetwarzaniem żądań w jednym miejscu, co daje mu dodatkowe możliwości, które pozwalają na realizację bardziej skomplikowanych zadań, niż zwykle rozwiązuje je kontroler strony. Nie będę wdawał się w szczegóły implementacji kontrolera strony, powiem tylko, że w części praktycznej będzie rozwijany kontroler żądań (coś podobnego).

1.2. Routing adresów URL Routing adresów URL umożliwia skonfigurowanie aplikacji tak, aby akceptowała żądania z adresów URL, które nie odpowiadają rzeczywistym plikom aplikacji, oraz korzystała z systemów CNC, które mają znaczenie semantyczne dla użytkowników i są preferowane do optymalizacji wyszukiwarek.

Na przykład dla zwykła strona, wyświetlając formularz informacja zwrotna, adres URL mógłby wyglądać następująco:
http://www.example.com/contacts.php?action=feedback

Przybliżony kod przetwarzania w tym przypadku:
switch ($_GET ["akcja" ]) ( case "about": require_once ("about.php" ); // Podział strony "O nas" ; case "contacts": require_once ("contacts.php" ); // strona „Kontakty” przerwa ; przypadek „opinia”: require_once („feedback.php” ); // strona „Feedback” przerwa; domyślnie: require_once („page404.php” ); // strona „404” przerwa ; )
Myślę, że prawie każdy już to kiedyś robił.

Korzystając z mechanizmu routingu adresów URL, możesz skonfigurować aplikację tak, aby akceptowała takie żądania, aby wyświetlić te same informacje:
http://www.example.com/contacts/feedback

Tutaj kontakty reprezentują kontroler, a informacja zwrotna to metoda kontrolera kontaktów, która wyświetla formularz opinii itp. Do tego zagadnienia powrócimy w części praktycznej.

Warto również wiedzieć, że routery wielu frameworków internetowych umożliwiają tworzenie niestandardowych tras URL (określ, co oznacza każda część adresu URL) i reguł ich przetwarzania.
Teraz mamy wystarczającą wiedzę teoretyczną, aby przejść do praktyki.

2. Ćwicz Najpierw twórzmy następująca struktura pliki i foldery:

Patrząc w przyszłość, powiem, że podstawowe klasy Model, View i Controller będą przechowywane w folderze core.
Ich dzieci będą przechowywane w katalogach kontrolerów, modeli i widoków. Plik Index.php jest punktem wejścia do aplikacji. Plik bootstrap.php inicjuje ładowanie aplikacji, podłączanie wszystkich niezbędnych modułów itp.

Pójdziemy sekwencyjnie; Otwórzmy plik Index.php i wypełnijmy go następującym kodem:
ini_set("błędy_wyświetlania" , 1 ); require_once "aplikacja/bootstrap.php" ;
Tutaj nie powinno być żadnych pytań.

Następnie przejdźmy od razu do pliku bootstrap.php:
require_once "core/model.php" ; require_once "core/view.php" ; require_once "core/controller.php" ; require_once "core/route.php" ; Trasa::start(); //uruchom router
Na razie połączą się pierwsze trzy linie nieistniejące pliki jądra. Ostatnie linie połącz plik z klasą routera i uruchom go do wykonania, wywołując metoda statyczna początek.

2.1. Implementowanie routera URL Na razie odejdźmy od implementacji wzorca MVC i skupmy się na routingu. Pierwszym krokiem, który musimy zrobić, to napisać następujący kod w .htaccess:
RewriteEngine On RewriteCond %(REQUEST_FILENAME) !-f RewriteCond %(REQUEST_FILENAME) !-d RewriteRule .* indeks.php [L]
Ten kod przekieruje całe przetwarzanie strony do pliku Index.php, czyli tego, czego potrzebujemy. Pamiętacie, jak w pierwszej części rozmawialiśmy o Front Controllerze?!

Umieścimy routing osobny plik Route.php do katalogu głównego. W tym pliku opiszemy klasę Route, która będzie uruchamiać metody kontrolera, które z kolei wygenerują widok strony.

Zawartość pliku Route.php

class Route ( funkcja statyczna start () ( // kontroler i domyślna akcja $controller_name = "Main" ; $action_name = "index" ; $routes = eksploduj("/" , $_SERVER ["REQUEST_URI" ]); // pobierz nazwa kontrolera if (!empty ($routes )) ( $controller_name = $routes ; ) // pobierz nazwę akcji if (!empty ($routes )) ( $action_name = $routes ; ) // dodaj przedrostki $model_name = " Model_" .$controller_name ; $controller_name = "Controller_" .$controller_name ; $action_name = "action_" .$action_name ; // podłącz plik z klasą modelu (może nie być pliku modelu) $model_file = strtolower ($nazwa_modelu ). ".php" ; $model_path = "application/models/" .$model_file ; if (file_exists($model_path )) (include "application/models/" .$model_file ; ) // podłącz plik z klasą kontrolera $controller_file = strtolower ($controller_name).php" ; $controller_path = "application/controllers/" .$controller_file ; if (file_exists($controller_path )) (include "application/controllers/" .$controller_file ; ) else ( /* poprawne byłoby zgłoszenie tutaj wyjątku, ale dla uproszczenia od razu przekierujemy na stronę 404 */ Route::ErrorPage404(); ) // utwórz kontroler $controller = new $controller_name ; $akcja = $nazwa_akcji ; if (method_exists($controller , $action )) ( // wywołaj akcję kontrolera $controller ->$action (); ) else ( // tutaj również rozsądniej byłoby zgłosić wyjątek Route::ErrorPage404(); ) ) funkcja ErrorPage404 ( ) ( $host = "http://" .$_SERVER ["HTTP_HOST" ]."/" ; header("HTTP/1.1 404 Nie znaleziono" ); header("Status: 404 Nie znaleziono" ); header("Lokalizacja:" .$host .404" ); ) )

Zauważam, że klasa implementuje bardzo uproszczoną logikę (pomimo obszernego kodu) i może nawet mieć problemy z bezpieczeństwem. Zrobiono to celowo, bo... napisanie pełnoprawnej klasy routingu zasługuje przynajmniej na osobny artykuł. Spójrzmy na główne punkty...

W elemencie tablica globalna$_SERVER["REQUEST_URI"] zawiera pełny adres, pod którym kontaktował się użytkownik.
Na przykład: example.ru/contacts/feedback

Korzystanie z funkcji eksplodować Adres jest podzielony na komponenty. W rezultacie otrzymujemy nazwę kontrolera, dla przykładu jest to kontroler Łączność i nazwa akcji, w naszym przypadku - informacja zwrotna.

Następnie łączy się plik modelu (może brakować modelu) i plik kontrolera, jeśli taki istnieje, po czym tworzona jest instancja kontrolera i ponownie wywoływana jest akcja, jeśli została opisana w klasie kontrolera.

Zatem jadąc pod adres np.:
przykład.com/portfolio
Lub
przykład.com/portfolio/index
Router wykona następujące czynności:

będzie zawierać plik model_portfolio.php z folderu models, zawierający klasę Model_Portfolio;

będzie zawierać plik kontroler_portfolio.php z folderu kontrolerów, zawierający klasę Controller_Portfolio;

utworzy instancję klasy Controller_Portfolio i wywoła opisaną w niej domyślną akcję action_index.

Jeśli użytkownik spróbuje uzyskać dostęp do adresu nieistniejącego kontrolera, na przykład:
przykład.com/ufo
następnie zostanie przekierowany na stronę „404”:
przykład.com/404
To samo stanie się, jeśli użytkownik uzyska dostęp do akcji, która nie jest opisana w kontrolerze.2.2. Wróćmy do implementacji MVC, przejdźmy do folderu core i dodajmy do pliku Route.php jeszcze trzy pliki: model.php, view.php i kontroler.php

Przypomnę, że będą one zawierać klasy bazowe, które teraz zaczniemy pisać.

Zawartość pliku model.php
klasa Model (funkcja publiczna get_data ( ) ( ) )
Klasa modelu zawiera pojedynczą, pustą metodę pobierania danych, która zostanie zastąpiona w klasach potomnych. Kiedy utworzymy klasy potomne, wszystko stanie się jaśniejsze.

Zawartość pliku view.php
widok klasy ( //public $template_view; // tutaj możesz określić domyślny widok ogólny. funkcja generate ($content_view , $template_view , $data = null) ( /* if(is_array($data)) ( // konwertuj tablicę elementy do zmiennych ekstrakt($data); ) */włącz „aplikację/widoki/” .$template_view ; ) )
Nietrudno zgadnąć, że to metoda Generować przeznaczony do tworzenia widoku. Przekazywane są do niego następujące parametry:

$content_file - widoki wyświetlające zawartość strony;

$template_file — szablon wspólny dla wszystkich stron;

$data to tablica zawierająca elementy treści strony. Zwykle wypełniane w modelu.

Funkcja include dynamicznie łączy ogólny szablon (widok), w którym widok zostanie osadzony
aby wyświetlić zawartość określonej strony.

W naszym przypadku ogólny szablon będzie zawierał nagłówek, menu, pasek boczny i stopkę, a zawartość stron będzie zawarta w oddzielny formularz. Ponownie zrobiono to dla uproszczenia.

Zawartość pliku kontroler.php
kontroler klasy ( publiczny $model ; publiczny $widok ; funkcja __construct () ( $this ->view = nowy widok(); ) ))
metoda indeks_akcji- jest to akcja wywoływana domyślnie, nadpiszemy ją przy implementacji klas potomnych.

2.3. Implementacja klas potomnych Model i Controller, tworzenie widoków. Teraz zaczyna się zabawa! Nasza witryna wizytówkowa będzie składać się z następujących stron:

dom

Usługi

Teczka

Łączność

A także - strona „404”.

Każda strona ma swój własny kontroler z folderu kontrolerów i widok z folderu widoków. Niektóre strony mogą wykorzystywać model lub modele z folderu modeli.

Na poprzednim rysunku osobno zaznaczony jest plik template_view.php - jest to szablon zawierający znaczniki wspólne dla wszystkich stron. W najprostszym przypadku mogłoby to wyglądać tak:
dom
Aby nadać witrynie reprezentacyjny wygląd, projektujemy Szablon CSS i zintegrować go z naszą witryną internetową, zmieniając strukturę znaczników HTML i Połączenia CSS i pliki JavaScript:

Na końcu artykułu, w sekcji „Wynik”, znajduje się link do repozytorium GitHub z projektem, w którym zostały podjęte kroki w celu integracji prostego szablonu.

2.3.1. Tworzenie strony głównej Zacznijmy od kontrolera kontroler_main.php , oto jego kod:
klasa Controller_Main rozszerza kontroler (funkcja action_index () ( $this ->view->generate("main_view.php" , "template_view.php" ); ) )
W metodzie Generować instancji klasy View przekazywane są nazwy plików szablonu ogólnego oraz widok z zawartością strony.
Oprócz akcji indeksowej kontroler może oczywiście zawierać inne akcje.

Plik z ogólna perspektywa patrzyliśmy wcześniej. Rozważmy plik zawartości main_view.php:
Powitanie! OLOLOSHA TEAM to zespół najwyższej klasy specjalistów w dziedzinie tworzenia stron internetowych z wieloletnim doświadczeniem w kolekcjonowaniu masek meksykańskich, posągów z brązu i kamienia z Indii i Cejlonu, płaskorzeźb i rzeźb stworzonych przez mistrzów Afryki Równikowej pięciu lub sześciu wieków temu...
Zawiera proste znaczniki bez żadnych wywołań PHP.
Aby wyświetlić stronę główną możesz skorzystać z jednego z poniższych adresów:

metody bibliotek realizujących abstrakcję danych. Na przykład metody biblioteki PEAR MDB2;
metody ORM;
metody pracy z NoSQL;
itd.

Chińskie telefony

Oparte na Androidzie

Klasa kontrolera modelu zawarta jest w pliku kontroler_portfolio.php, oto jej kod:
klasa Controller_Portfolio rozszerza kontroler ( funkcja __construct () ( $this ->model = nowy Model_Portfolio(); $this ->view = nowy View(); ) funkcja action_index () ( $data = $this ->model->get_data( ); $this ->view->generate("portfolio_view.php" , "template_view.php" , $data ); ) )
Do zmiennej dane zapisywana jest tablica zwrócona przez metodę otrzymać dane które oglądaliśmy wcześniej.
Zmienna ta jest następnie przekazywana jako parametr metody Generować, który zawiera także: nazwę pliku z szablonem ogólnym oraz nazwę pliku zawierającego widok z zawartością strony.

Widok zawierający zawartość strony znajduje się w pliku portfolio_view.php.
Teczka

prosta konstrukcja

Witamy w drugim artykule o MVC i PHP. Omówimy w nim kilka zasad, którymi należy się kierować podczas korzystania z architektury MVC.

Implementacja MVC za pomocą za pomocą PHP online może być nieco trudniej. Pierwszy problem związany jest z routingiem adresów URL. Routing adresów URL to jeden z aspektów, który nie został wzięty pod uwagę podczas opracowywania MVC.

Jakie zatem mamy możliwości rozwiązania problemu routingu adresów URL? Jednym z nich jest predefiniowanie wszystkich adresów URL, których potrzebuje aplikacja internetowa. A następnie przechowywanie ich w pamięci wraz z odpowiednimi danymi, które szablony „ Modele», « Reprezentacja" I " kontroler» są ładowane dla każdej strony lub sekcji.

Następnie system otrzymuje adres URL żądany przez użytkownika i ładuje komponenty przypisane do tej strony. Jest to praktyczne rozwiązanie, jeśli tworzysz witrynę firmową lub witrynę statyczną, która nie działa z dynamicznymi adresami URL. Na przykład:

Szablon PHP MVC jest przekazywany przez „ Model", do którego można przypisać szablon w zależności od tego, co konkretnego " Wydajność" Ta szablonowa metoda pozwala na tworzenie wydajnych i rozszerzalnych systemów, zapewniając możliwość oddzielenia rozwoju back-end i front-end. To jest główny cel MVC.

MVC przeszedł poważne zmiany od czasu jego pierwszego użycia w programowaniu. Był i nadal jest jednym z najczęściej dyskutowanych tematów wśród deweloperów. Debata ta stała się jeszcze bardziej intensywna po użyciu MVC do programowania PHP dla Internetu.

Tłumaczenie artykułu „Wzorzec MVC i PHP. Część 2” została przygotowana przez zaprzyjaźniony zespół projektu Budowa Strony Internetowej od A do Z.

Być może słyszałeś nawet o wzorcach projektowych, a nawet przeglądałeś te wspaniałe książki:

E. Gamma, R. Helm, R. Johnson, J. Vlissides „Techniki projektowania obiektowego. Wzorce projektowe";
M. Fowler „Architektura aplikacji dla przedsiębiorstw”.

Doświadczeni programiści PHP raczej nie znajdą w tym artykule nic nowego dla siebie, ale ich komentarze i komentarze do tekstu głównego będą bardzo pomocne! Ponieważ Bez teorii praktyka jest niemożliwa, a bez praktyki teoria jest bezużyteczna, potem najpierw będzie trochę teorii, a potem przejdziemy do praktyki. Jeśli znasz już koncepcję MVC, możesz pominąć część teoretyczną i przejść od razu do praktyki.

Przyjrzyjmy się diagramowi koncepcyjnemu wzorca MVC (moim zdaniem jest to najbardziej udany diagram, jaki widziałem):

W architekturze MVC model zapewnia reguły dotyczące danych i logiki biznesowej, widok odpowiada za interfejs użytkownika, a kontroler zapewnia interakcję pomiędzy modelem a widokiem.

Typowy przepływ aplikacji MVC można opisać w następujący sposób:

Gdy użytkownik odwiedza zasób sieciowy, skrypt inicjujący tworzy instancję aplikacji i uruchamia ją do wykonania.
Wyświetla widok, powiedzmy, strony głównej witryny.
Aplikacja odbiera żądanie od użytkownika i określa żądany kontroler oraz akcję. W przypadku strony głównej wykonywana jest akcja domyślna ( indeks).
Aplikacja tworzy instancję kontrolera i uruchamia metodę akcji,
który zawiera na przykład wywołania modelu odczytujące informacje z bazy danych.
Następnie akcja tworzy widok z danymi uzyskanymi z modelu i wyświetla wynik użytkownikowi.

Kontroler to spoiwo łączące modele, widoki i inne komponenty w działającą aplikację. Administrator odpowiada za przetwarzanie żądań użytkowników. Kontroler nie powinien zawierać zapytań SQL. Lepiej trzymać je w modelach. Kontroler nie powinien zawierać kodu HTML ani innych znaczników. Warto mieć to na uwadze.
W dobrze zaprojektowanej aplikacji MVC kontrolery są zwykle bardzo cienkie i zawierają tylko kilkadziesiąt linii kodu. Tego samego nie można powiedzieć o Stupid Fat Controllers (SFC) w CMS Joomla. Logika kontrolera jest dość typowa i w większości przeniesiona do klas bazowych.
Modele natomiast są bardzo grube i zawierają większość kodu związanego z przetwarzaniem danych, ponieważ struktura danych i zawarta w nich logika biznesowa są zwykle dość specyficzne dla konkretnej aplikacji.

Mam nadzieję, że już zauważyłeś, że różne witryny mogą mieć zupełnie różne formaty konstruowania paska adresu. Każdy format może wyświetlać architekturę aplikacji internetowej. Chociaż nie zawsze tak jest, w większości przypadków jest to oczywisty fakt.

Rozważmy dwie opcje paska adresu, które wyświetlają tekst i profil użytkownika.

Przybliżony kod przetwarzania w tym przypadku:
switch($_GET["akcja"]) ( case "about" : require_once("about.php"); // Podział strony "O nas"; case "contacts": require_once("contacts.php"); // Podział strony „Kontakty”; przypadek „opinia”: require_once(”feedback.php”); // Podział strony „Opinia”; domyślnie: require_once("page404.php"); // strona "404" przerwa; )
Myślę, że prawie każdy już to kiedyś robił.

Korzystając z mechanizmu routingu adresów URL, możesz skonfigurować aplikację tak, aby akceptowała takie żądania, aby wyświetlić te same informacje:
http://www.example.com/contacts/feedback

Tutaj kontakty reprezentują kontroler, a informacja zwrotna to metoda kontrolera kontaktów, która wyświetla formularz opinii itp. Do tego zagadnienia powrócimy w części praktycznej.

Pójdziemy sekwencyjnie; Otwórzmy plik Index.php i wypełnijmy go następującym kodem:
ini_set("błędy_wyświetlania", 1); require_once "aplikacja/bootstrap.php";
Tutaj nie powinno być żadnych pytań.

Następnie przejdźmy od razu do pliku bootstrap.php:
require_once "core/model.php"; require_once "core/view.php"; require_once "core/controller.php"; require_once "core/route.php"; Trasa::start(); //uruchom router
Pierwsze trzy linie będą zawierać aktualnie nieistniejące pliki jądra. Ostatnie linie zawierają plik z klasą routera i uruchamiają go do wykonania wywołując metodę static start.

Umieścimy routing w oddzielnym pliku Route.php w katalogu głównym. W tym pliku opiszemy klasę Route, która będzie uruchamiać metody kontrolera, które z kolei wygenerują widok strony.

Zawartość pliku Route.php

class Route ( funkcja statyczna start() ( // kontroler i domyślna akcja $controller_name = "Main"; $action_name = "index"; $routes = eksploduj("/", $_SERVER["REQUEST_URI"]); // pobierz nazwa kontrolera if (!empty($routes)) ( $controller_name = $routes; ) // pobierz nazwę akcji if (!empty($routes)) ( $action_name = $routes; ) // dodaj przedrostki $model_name = " Model_".$nazwa_kontrolera; $nazwa_kontrolera = "Kontroler_".$nazwa_kontrolera; $nazwa_akcji = "akcja_".$nazwa_akcji; // połącz plik z klasą modelu (może nie być pliku modelu) $model_file = strtolower ($model_name).".php"; $model_path = "application/models/".$model_file; if(file_exists($model_path)) (include "application/models/".$model_file; ) // podłącz plik z klasą kontrolera $plik_kontrolera = strtolower ($nazwa_kontrolera)..php"; $ścieżka_kontrolera = "aplikacja/kontrolery/".$plik_kontrolera; if(plik_istnieje($ścieżka_kontrolera)) (w tym "aplikacja/kontrolery/".$plik_kontrolera; ) else ( /* poprawne byłoby zgłoszenie tutaj wyjątku, ale dla uproszczenia od razu przekierujemy na stronę 404 */ Route::ErrorPage404(); ) // utwórz kontroler $controller = new $controller_name ; $akcja = $nazwa_akcji; if(method_exists($controller, $action)) ( // wywołaj akcję kontrolera $controller->$action(); ) else ( // tutaj również rozsądniej byłoby zgłosić wyjątek Route::ErrorPage404(); ) ) funkcja ErrorPage404( ) ( $host = "http://".$_SERVER["HTTP_HOST"]."/"; header("HTTP/1.1 404 nie znaleziono"); header("Status: 404 nie znaleziono") ; nagłówek(" Lokalizacja:.$host.."404"); ) )

Globalny element tablicy $_SERVER["REQUEST_URI"] zawiera pełny adres, z którym kontaktował się użytkownik.
Na przykład: example.ru/contacts/feedback

Zatem jadąc pod adres np.:
przykład.com/portfolio
Lub
przykład.com/portfolio/index
Router wykona następujące czynności:

będzie zawierać plik model_portfolio.php z folderu models, zawierający klasę Model_Portfolio;
będzie zawierać plik kontroler_portfolio.php z folderu kontrolerów, zawierający klasę Controller_Portfolio;
utworzy instancję klasy Controller_Portfolio i wywoła opisaną w niej domyślną akcję - action_index.

Przypomnę, że będą one zawierać klasy bazowe, które teraz zaczniemy pisać.

Zawartość pliku model.php
klasa Model (funkcja publiczna get_data() ( ) )
Klasa modelu zawiera pojedynczą, pustą metodę pobierania danych, która zostanie zastąpiona w klasach potomnych. Kiedy utworzymy klasy potomne, wszystko stanie się jaśniejsze.

Zawartość pliku view.php
widok klasy ( //public $template_view; // tutaj możesz określić domyślny widok ogólny. funkcja generate($content_view, $template_view, $data = null) ( /* if(is_array($data)) ( // konwertuj tablicę elementy do zmiennych ekstrakt($data); ) */włącz „application/views/”.$template_view; ) )
Nietrudno zgadnąć, że to metoda Generować przeznaczony do tworzenia widoku. Przekazywane są do niego następujące parametry:

$content_file - widoki wyświetlające zawartość strony;
$template_file - szablon wspólny dla wszystkich stron;
$data to tablica zawierająca elementy treści strony. Zwykle wypełniane w modelu.

W naszym przypadku ogólny szablon będzie zawierał nagłówek, menu, pasek boczny i stopkę, a zawartość strony będzie zawarta w osobnej formie. Ponownie zrobiono to dla uproszczenia.

Zawartość pliku kontroler.php
kontroler klasy ( publiczny $model; publiczny $widok; funkcja __construct() ( $this->view = nowy widok(); ) funkcja action_index() ( ) )
metoda indeks_akcji- jest to akcja wywoływana domyślnie, nadpiszemy ją przy implementacji klas potomnych.

dom
Usługi
Teczka
Łączność
A także - strona „404”.

Na poprzednim rysunku osobno zaznaczony jest plik template_view.php - jest to szablon zawierający znaczniki wspólne dla wszystkich stron. W najprostszym przypadku mogłoby to wyglądać tak:
dom
Aby nadać witrynie reprezentacyjny wygląd, tworzymy szablon CSS i integrujemy go z naszą witryną, zmieniając strukturę znaczników HTML i łącząc pliki CSS i JavaScript:

Na końcu artykułu, w sekcji „Wynik”, znajduje się link do repozytorium GitHub z projektem, w którym zostały podjęte kroki w celu integracji prostego szablonu.

Generować

Wcześniej sprawdziliśmy plik widoku ogólnego. Rozważmy plik zawartości main_view.php:
Powitanie!

ZESPÓŁ OLOLOSHA- zespół najwyższej klasy specjalistów w dziedzinie tworzenia stron internetowych z wieloletnim doświadczeniem w kolekcjonowaniu masek meksykańskich, posągów z brązu i kamienia z Indii i Cejlonu, płaskorzeźb i rzeźb stworzonych przez mistrzów Afryki Równikowej pięć lub sześć wieków temu. ..

metody natywnych bibliotek pgsql lub mysql;
metody bibliotek realizujących abstrakcję danych. Na przykład metody biblioteki PEAR MDB2;
metody ORM;
metody pracy z NoSQL;
itd.

Klasa kontrolera modelu zawarta jest w pliku kontroler_portfolio.php, oto jej kod:
klasa Controller_Portfolio rozszerza kontroler ( funkcja __construct() ( $this->model = nowy Model_Portfolio(); $this->view = nowy View(); ) funkcja action_index() ( $data = $this->model->get_data( ); $this->view->generate("portfolio_view.php", "template_view.php", $data); ) )
Do zmiennej dane zapisywana jest tablica zwrócona przez metodę otrzymać dane które oglądaliśmy wcześniej.
Zmienna ta jest następnie przekazywana jako parametr metody Generować, który zawiera także: nazwę pliku z szablonem ogólnym oraz nazwę pliku zawierającego widok z zawartością strony.

Widok zawierający zawartość strony znajduje się w pliku portfolio_view.php.
Teczka

Rok

Projekt

Opis

Rok

Projekt

Opis

Zrzut ekranu powstałej witryny z wizytówkami

Ale w tej wersji naszkicowałem następujące klasy (i odpowiadające im typy):

Controller_Login w którym generowany jest widok z formularzem wpisania loginu i hasła, po jego wypełnieniu przeprowadzana jest procedura uwierzytelnienia i w przypadku pozytywnego wyniku użytkownik zostaje przekierowany do panelu administracyjnego.
Contorller_Admin z akcją indeksującą, która sprawdza, czy użytkownik był wcześniej autoryzowany w serwisie jako administrator (jeśli tak, wyświetla się widok panelu administracyjnego) oraz akcją wylogowania w celu wylogowania.

złożone rozwiązania

krótkoterminowy

Jednak używanie frameworków sieciowych takich jak Yii czy Kohana, składających się z kilkuset plików, przy tworzeniu prostych aplikacji internetowych (na przykład witryn z wizytówkami) nie zawsze jest wskazane. Teraz możemy stworzyć piękny model MVC, aby nie mieszać PHP, HTML, CSS i Kod JavaScript w jednym pliku.

Ten artykuł jest bardziej punktem wyjścia do nauki CMF niż przykładem czegoś naprawdę poprawnego, co możesz wykorzystać jako podstawę swojej aplikacji internetowej. Być może nawet Cię to zainspirowało i już myślisz o napisaniu własnego mikroframeworku lub CMS-a opartego na MVC. Zanim jednak wymyślisz na nowo koło z „blackjackem i dziwkami”, zastanów się jeszcze raz: może rozsądniej byłoby skierować swoje wysiłki na rozwój i pomoc społeczności już istniejącego projektu?!

P.S: Artykuł został przepisany z uwzględnieniem komentarzy pozostawionych w komentarzach. Krytyka okazała się bardzo przydatna. Sądząc po odzewach: komentarzach, PW i liczbie użytkowników, którzy dodali post do ulubionych, pomysł napisania tego wpisu okazał się nie taki zły. Niestety nie da się uwzględnić wszystkich życzeń i napisać więcej i bardziej szczegółowo ze względu na brak czasu... ale być może zrobią to te tajemnicze osoby, które minusowały pierwotną wersję. Powodzenia w realizacji projektów!

Tagi:

php
struktura
cmf
mvc
strona