Podstrony
- telcocafe
- [PHP+MySQL] Problem z połączeniem mysqli('localhost', 'xxx', 'xxx', 'xxx'
- [PHP] Wyrażenia regularne. Zamienić name="info_imie" na name="{info_imie}"
- [php] Dodanie textu do pliku. Problem... :) POMOCY!!!!!!!!!!!!!
- [PHP] Skrypt cenzury Chcę cenzury!!!
- Dobre programy do edycji php Dobre programy do edycji php
- [PHP] podział na strony php: podział na strony
- [PHP i MySQL] jak pobrac liczbe rezultatow Jak pobrac liczbe rezultatow???
- jak zrobic aktualizacje php? pomocy!!!!!
- Błąd w PHP-Fusion pomocy !!!!!
- Daczego nie dziala?? skrypt php nie chce działać!!!
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- 6niebo.xlx.pl
telcocafe
Przeczytałem w Dziennikach Gwiazdowych artykuł o wzorcu MVC w PHP. Większość szkieletów korzysta z wzorca MVP, czyli Model View Presenter. Autor zajął się wzorcem MVC, czyli Model View Controller, w którym można wykorzystać jedną warstwę V dla kilku podstron. Wszystko fajnie, ale mam dużo wątpliwości.Wydajność
Podział na modele, widoki, kontroler i akcje, a także obecność dodatkowych bibliotek wymusza dołączanie wielu plików. Z moich badań wynika, że wywoływanie metod jest wolne, a po załadowaniu N klas i funkcji wzrasta użycie pamięci. Najbardziej czasochłonne są operacje na bazie danych i na dysku, na bardzo długich ciągach tekstowych, skomplikowane obliczenia matematyczne... Właściwie wszystko można przekombinować. Zorganizowana struktura obiektowa pozwala jednak uprościć część operacji i stworzyć wydajny system cache, dlatego narzut czasowy można zlikwidować.
Uniwersalne widoki
Przykładem są listy elementów, czyli typowa siatka. Może obsługiwać stronicowanie i inne wspólne elementy. Może się zdarzyć, że pewna podstrona będzie potrzebować jeszcze innego, unikalnego elementu albo inaczej wyświetlać część danych (z tym, że nadal głównym elementem będzie lista). Czy należy pchać tak dużo funkcjonalności do widoków, ile się da?
Szablony
Jeżeli postawimy na uniwersalne widoki, szablony też staną się zagmatwane i ciężko będzie je pojąć grafikom, twórcom kodu HTML / CSS, niezależnie od składni języka szablonowego (XML, komentarze HTML, Smarty).
Rozszerzenia
Wydaje się, że łatwiej wprowadzić obsługę rozszerzeń modyfikujących funkcjonalność i interfejs w obiektowej strukturze. Jest trochę wzorców projektowych, np. obserwator, dekorator, odwiedzający...
Główny kontroler
Mam wątpliwości, czy rzeczywiście jest potrzebny skomplikowany front kontroler, którego celem jest tylko wyplucie danych i przyjmowanie żądań. Reszta kontrolerów zależy od grupy podstron, np. inny dla forum, inny dla profilów użytkowników, inny dla zawartości - o to w tym chodzi?
Baza danych
Aby łączyć się z bazą tylko wtedy, kiedy potrzeba, prawdopodobnie trzeba stworzyć nakładkę na PDO lub MySQLi. Chociaż niekoniecznie. To zależy od sposobu implementacji.
Równowaga abstrakcji i prostoty kodu
Jak ją osiągnąć? Jak nie przesadzić z klasami / funkcjami, ale stworzyć porządne API?
Kiedy stosować przestrzenie nazw
Jakieś przykłady konkretnych przypadków, kiedy są koniecznie potrzebne w języku PHP?
MVC czy MVP?
Który wzorzec jest lepszy dla aplikacji internetowych i dlaczego? A może żaden z nich?
To podstawowe pytania. Mam więcej wątpliwości. Jeżeli przypomnę sobie, zaraz napiszę.
MVP to w zasadzie odmiana MVC.
Ściągnij sobie gotowy framework i przejrzyj rozwiązania.
Np. w CakePHP masz kontroler główny, który wykonuje tylko bardzo ogólne zadania(często praktycznie nic - w zasadzie ogranicza się do deklaracji i istnieje tylko pro forma) - po nim dziedziczą kontrolery odpowiedzialne za poszczególne części strony(artykuły, zdjęcia, etc) i do niego przypisane są widoki(po jednym do każdej funkcji w klasie kontrolera) - standardowo: view, edit, add, index, ale można to rozwinąć zupełnie dowolnie.
Jednak przypisanie nie jest sztywne i jeśli w jakimś wypadku potrzebujesz inny widok/layout to wystarczy przypisać stosowną nazwę do odpowiedniej zmiennej - to załatwia Twój problem unikalnych elementów, celem kontrolera jest właśnie wybranie danych do wyświetlenia, więc jeśli mamy dwie listy różniące się zawartością to właśnie kontroler ma wybrać potrzebne dane i wysłać je do widoku.
Dlatego szablony są niesamowicie proste - nie ma tam żadnych mechanizmów decyzyjnych - czysty html, echo, pętle i ewentualnie odwołania do funkcji wstawiających elementy zgodnie z przyjętą konwencją(co sprawia, że np zmiana sposobu konstruowania urli nie wymaga zmian w widokach). Nie ma tu mowy o jakimkolwiek zagmatwaniu.
Język szablonowy wg. mnie to najzwyklejsze marnowanie czasu procesora - no chyba, że mamy kilka projektów w różnych językach i chcemy ujednolicić pracę front-endowcom, ale nie wydaje mi się, żeby takie przypadki zbyt często występowały w naturze.
Jeśli chodzi o dostęp do bazy to z bezpośredniego formułowania zapytań na co dzień się nie korzysta - framework pozwala wygodniej pobierać dane, a jednocześnie automatycznie zapewnia walidację - jest funkcja pozwalająca na praktycznie normalne zapytanie, ale używa się jej od święta.
Wydajność
Podział na modele, widoki, kontroler i akcje, a także obecność dodatkowych bibliotek wymusza dołączanie wielu plików. Z moich badań wynika, że wywoływanie metod jest wolne, a po załadowaniu N klas i funkcji wzrasta użycie pamięci. Najbardziej czasochłonne są operacje na bazie danych i na dysku, na bardzo długich ciągach tekstowych, skomplikowane obliczenia matematyczne... Właściwie wszystko można przekombinować.
Nadal nie rozumiesz co to jest optymalizacja i wydajność. Frameworku nie stosuje się po to by mieć kod o parę ns szybszy, tylko żeby mieć kod, który można rozbudowywać i utrzymywać a nie wielką kulę błota - bo po paru tysiąciach linii kodu takiej kuli nie ogarniesz... a jak dość prosta aplikacja będzie miała kilkanaście tysięcy?.
Jakoś nie zauważyłem żeby framework wykonywał skomplikowane obliczenia matematyczne, czy operacje na długich ciągach testowych. Zauważyłem natomiast że tworzenie aplikacji webowych za pomocą frameworka przebiesza bardzo szybko i sprawnie, szczególnie gdy framework jest "kompletny". U mojego pierwszego pracodawcy był firmowy framework i wszystko musiało być robione w nim zgodnie z jego API, a powód prosty - raz że różni programiści mogli pracować po sobie nad aplikacją, a dwa że był porządek i ogólna stabilność kodu (choć brakowało na tym etapie zautomatyzowanych testów). W Goldenline doszły zewnętrzne usługi i aplikacje jak wyszukiwanie przez Sphinxa, czy rozdział serwerów bazodanych na te do zapisu i na te do odczytu, czy replikację statyki - wszystkich zdjęć i to też musiało dobrze integrować się z frameworkami (Django i PHPowym w głównym serwisie) tak by nie trzeba było modyfikować ogromnych ilości kodu. Framework przewiduje wiele aspektów, które zazwyczaj się pomija pisząc "po swojemu" (a po swojemu sporo też na początku programowania pisałem to wiem jak to wygląda ;)).
Projekty amatorskie, jednoosobowe itd. praktycznie nigdy nie osiągną takiego ruchu by wymagać skalowalności ponad poziom dawany przez dobrze napisaną aplikację we frameworku. A gdy taka potrzeba zajdzie to serwis już mały nie jest... i podstawowa optymalizacja - wieloserwerowa konfiguracja to żaden problem.
Co do szablonów - jest podobnie. Smarty, czy np. system szablonów Django są tak zaprojektowane by mógł pracować przy nich frontendowiec, "grafik" (nie mylić z "grafikiem" co zrobi szablon html i tyle go to obchodzi). Masz dziedziczenie, tagi i filtry - i to sprawdza się bardzo dobrze. Tworzysz 1-więcej szablonów szkieletowych z blokami a widoki tylko wypełniają je treścią. Koniec końców i tak to później leży skompilowane do PHP/języka frameworka.
Poza tym MVC to nie framework. Między działającą implementacją wzorca a sensownym frameworkiem masz setki roboczogodzin doświadczonych programistów. Jedna osoba zajmująca się programowaniem amatorsko sama niczego tak wartościowego nie stworzy, dlatego warto korzystać z takich narzędzi.
Użytkownik Riklaunim edytował ten post 27 czerwiec 2010, 17:23