Wzorowa podstawa
Już dość dawno temu obiecałem tekst o frameworkach i wzorcach projektowych. Dziś mam odrobinę wolnego czasu, który poświęcę by spisać kilka informacji na ten temat. Może się komuś przyda?
Zacznę od wzorców projektowych*. W procesie tworzenia aplikacji (zwłaszcza internetowych, wyposażonych w interfejs i część coreową) ważne jest, by wybrać i konsekwentnie trzymać się pewnych założeń. Od najprostszych i najbardziej szczegółowych (nazywanie metod w języku angielskim, nazywanie ich w konkretny, czytelny sposób itd.) do tych najbardziej ogólnych (struktura katalogowa itd.). Na całe szczęście programowanie nie zostało wymyślone rok temu, wiele już zostało zrobione w tej dziedzinie. Wzorców projektowych nawet w PHP jest wiele, ale najlepiej (moim zdaniem) zacząć naukę poważnego projektowania od opanowania pisania w MVC.
Model-Controller-View
Wzorzec MVC nastawiony jest przede wszystkim na rozdzielenie powierzchni logicznej od tej dostępnej użytkownikowi. Dlatego utworzone na użytek wzorca zostały trzy pojęcia:
Model - czyli część aplikacji odpowiedzialna za komunikację z bazą danych. View - czyli część aplikacji odpowiedzialna za wyświetlanie interfejsu. Controller - czyli część aplikacji, która tak naprawdę służy do "porozumiewania" się wcześniejszych dwóch części.
Tak teoretycznie to naprawdę nie jest łatwe do wytłumaczenia. W praktyce okazuje się jednak dużo prostsze. Zacznijmy od teoretycznej struktury katalogów w aplikacji:
/. ..Model ______...htaccess ______..model.class.php ..View ______...htaccess ______..view.class.php ..Controller ______...htaccess ______..controller.class.php ..index.php ...htaccess
Z góry przepraszam, za skandaliczne formatowanie... Mam nadzieję, iż widać na powyższym... e... czymś, co powinno przypominać strukturę folderów, że aplikacja składa się z trzech folderów (Model, View, Controller) 4 plików typu .htaccess, 3 klas oraz jednemu plikowi index.php. Jak wygląda działanie aplikacji? Wywołanie index.php powoduje przekazanie do kontrolera danych w tablicy POST, COOKIE oraz GET (o samym gecie za chwilę). Kontroler na podstawie tych tablic wywołuje metody klasy model.class.php, które przekazują w odpowiedzi żądane dane z powrotem do kontrolera, a na ich podstawie kontroler ładuje odpowiednie metody z klasy widoku. Konkretniej?
Index.php zawiera (domyślnie) formularz logowania. Użytkownik loguje się, dane logowania otrzymuje kontroler. Odpowiednio je obrabia (sleshuje i przeprowadza inne operacje, które wykluczą próby włamania się do aplikacji), a następnie wywołuje metodę z klasy model auth_user(). Ta metoda przyjmuje dwa argumenty (login i hasło), a następnie zwraca TRUE lub FALSE, w zależności od poprawności danych wejściowych. Odpowiedź otrzymuje kontroler i uruchamia odpowiednie metody tym razem klasy widok. Załóżmy, że dane są poprawne - kontroler przekazuje uruchamia metodę show_site() z argumentem o loginie użytkownika. Metoda jest po prostu szablonem strony, z miejscem na ów nick. O tym czym są szablony były już na dobrychprogramach artykuły.
I to cała filozofia pracy w MVC. Teoretycznie wydawać się może, że pracy zgodnie z tym wzorcem jest więcej, niż pisząc wszystko "ciągiem". Tutaj, by zobaczyć wyniki prostego zdania trzeba grzebać w trzech klasach. Zysk widoczny jest jednak najbardziej, gdy rozszerzamy naszą aplikację lub "pożyczamy" kod do innej.
CodeIgniter
Teraz kolej na framework. Framework to po prostu gotowa i w sporym stopniu uniwersalna podstawa aplikacji. A dokładniej... a dokładniej to zbiór klas, które ułatwiają nam pisanie kodu. Po frameworku spodziewać się można gotowych klas do łączenia się z bazą danych, które za nas pamiętają o odpowiednim zabezpieczeniu danych wejściowych, tworzenia ciasteczek, czy wsparcia dla "koszyków sklepowych". Wszystko to bowiem zostało już kiedyś napisane i nie trzeba wynajdować od nowa.
Sam CodeIgniter przy pierwszym spotkaniu przypominał mi Zenda. Zend z drugiej strony jest przeogromnym, rozbudowanym do granic, ale za to także wszechstronnym frameworkiem. CI natomiast jest lekki, wydajny, również wszechstronny, ale przede wszystkim - bardzo prosty w opanowaniu. Dodatkowo posiada doskonały user guide, który zawiera dokładne opisy wszystkich metod, wraz z przykładami użycia. Na stronie projektu zobaczyć można również 30 minutowy film, na którym obserwować można stworzenie prostego (prostackiego wręcz) bloga. Film ten jednak demonstruje doskonale potencjał frameworka. Trzeba jednak przyznać, że filmy są dość stare i pokazują niektóre elementy, które zostały wycofane. Cóż to jednak za problem, skoro wikipedia projektu zawiera kilkadziesiąt różnych filmów instruktażowych.
Przyszła pora na powrót do tablicy GET. Programiści projektu CI wychodzą (z bardzo słusznego moim zdaniem) założenia, ze tablica GET to zło. Dlatego sugerują by w ogóle z niej zrezygnować. W zamian proponują (dzięki mod_rewrite) ciekawy, ale nie oryginalny sposób wywoływania żądań. Polega on na tym, że elementy adresu URL przekładane są na nazwy klas (a w zasadzie to nazw plików, które zawierają klasy o tej samej nazwie) controllera oraz metod tych klasy. To może przykład:
http://example.com/blog/show_articles
Wywołanie tego adresu spowoduje uruchomienie metody show_articles z klasy blog. Oczywiście część tych parametrów może zostać domyślnie załadowana. Framework posiada parametr zawierający domyślny controller. Dlatego można tak skonfigurować (żeby nie napisać - zaprogramować) framework by wywołanie adresu:
http://example.com/
spowodowało uruchomienie klasy blog i jej metody index().
Na sam koniec podaje linka do user guide frameworka CodeIgniter. Zawiera on wiele przydatnych informacji nie tylko o samym CI, ale także mnóstw cennych informacji dla wszystkich programistów (o samym MVC, o zasadach formatowania kodu i wiele innych). O tym wszystkim poczytacie tutaj.
*Piszę o PHP, nie dla wszystkich języków jest to przekładalne, ale dla sporej części tak
PS. Wyszło mi to jakoś tak... nijak.