Praca inżynierska w toku, powoli klaruje się także sytuacja z zaliczeniami na uczelni, także mogę uznać, że wszystko idzie w dobrym kierunku do otrzymania trzech literek i kropki przed nazwiskiem. Mam nadzieję, że uda się zrobić wszystko w wymaganym terminie i „obronić się” w lutym. Dzisiaj poczyniłem kolejny krok do załatwienia spraw uczelnianych – przedstawiłem drugą i ostatnią prezentację na Seminarium Dyplomowym. Zapraszam do przejrzenia tego, co przygotowałem.
Wstęp.
Tym, którzy nie są w temacie proponuję lekturę poprzedniego wpisu o pierwszej prezentacji na temat bibliotek ORM. Wyjaśniłem tam dokładnie całą ideę przedmiotu oraz wymagania postawione przed studentami. Z informacji, jakie zawarłem w nagłówku tego posta znalazła się informacja o tym, że druga prezentacja musi mieć temat taki sam lub co najmniej związany z tematem pracy inżynierskiej. Nie podzieliłem się tym z Wami ostatnio, dlatego czynię to dzisiaj. Mój temat pracy inżynierskiej to:
Projektowanie i architektura frameworka w języku PHP.
Dlaczego taki temat? Otóż, nie lubię tworzyć rozwiązań docelowych, jednorazowych. Pomimo tego, że lubię programowanie webowe, to samo „dłubanie” kolejnych CMSów i portali internetowych jest mało ciekawe – o ile nie robi się tego w sposób usystematyzowany i nie rozwija się własnej, dobrze znanej bazy kodu [ok, tłumaczenie słowa "codebase" trochę kuleje, ale mam nadzieję, że się rozumiemy].
To, co najbardziej mnie interesuje to projektowanie i programowanie bibliotek, które można wykorzystać w dalszej pracy – komponentów stanowiących całość i zamykających w sobie dobrze znaną listę funkcji. Tworzenie nowego frameworka to generalnie zły pomysł i tak powie Wam każdy programista mający doświadczenie w branży. Idea stojąca za tym stwierdzeniem jest bardzo prosta – czy naprawdę komuś może się wydawać, że jest w stanie stworzyć coś lepszego niż dostępny na rynku produkt rozwijany przez rzeszę developerów i przetestowany w tysiącach rozwiązań? Postawione pytanie jest co najmniej retoryczne.
Biorąc pod uwagę właśnie to stwierdzenie chciałbym wyjaśnić pobudki, które skłoniły mnie do wyboru takiego, a nie innego tematu. Jest to praca inżynierskiej, a więc praca, w której będę musiał zaprezentować i udowodnić posiadanie wiedzy dotyczącej tworzenia konkretnych rozwiązań technicznych. W przypadku kierunku, jakim jest Informatyka sprowadza się to do zdolności zaprojektowania pewnej struktury, zastosowania odpowiednich wzorców projektowych i udowodnienia poprawności wykonanego oprogramowania. Ze względu na to, że nie miałem żadnego przekonywującego mnie pomysłu na wyspecjalizowaną bibliotekę, stwierdziłem, że warto będzie zmierzyć się ze stworzeniem rozwiązania ogólnego.
Zamierzam zawrzeć w tym frameworku wszystkie [a raczej te najlepsze / które pamiętam ;]] pomysły i doświadczenie, jakie nabyłem podczas kilku lat rozwoju w branży. Nie chcę się nastawiać na krytykę podważającą sam cel pracy – chcę po prostu sprawdzić swoje możliwości i oddać społeczności coś, co być może znajdzie pewien odzew i chęć dalszego rozwijania. Jako, że lubię tworzyć rozwiązania kompletne, nie będę pod żadnym pozorem w istotny sposób kopiował istniejących frameworków – chcę zapewnić po prostu dobry jakościowo kod, który nie będzie potrzebował rozbudowy konceptualnej – jak to napisałem na jednym ze slajdów – „There’s too much frame, not enough work”. Chciałbym spróbować to zmienić.
Prezentacja.
To tyle w kwestii teorii. Prezentację poświęciłem oczywiście na omówienie struktury i pewnego spojrzenia na sposób tworzenia tego typu oprogramowania. Tym razem prawie całe wystąpienie było w języku ojczystym, jedynie omówienie / streszczenie tematu było po angielsku – taki był wymóg doktora prowadzącego przedmiot, do czego się chętnie dostosowałem.
Zainteresowanych oczywiście zapraszam do przejrzenia przygotowanego przeze mnie materiału w tradycyjnie dwóch egzemplarzach:
- ODP – OpenDocument Presentation, format programu OpenOffice.org Impress.
- PDF – Portable Document Format, czyli znany i lubiany PDF.
W miarę możliwości poprosiłbym o wszelkie opinie i komentarze na temat jakości tej prezentacji. Każdy może się pomylić, a mi zależy na dostarczaniu poprawnych i wartościowych informacji, także kto je będzie weryfikował, jeśli nie Wy, Czytelnicy? ;] Informacje zawarte w tej prezentacji na pewno pomogą zrozumieć ideę stojącą za frameworkami i przynajmniej w stopniu podstawowym wyjaśnić ich działanie. Wzorce projektowe opisane w poszczególnych slajdach uważam za bardzo przydatne i naprawdę polecam dogłębne ich zrozumienie – pozwala to na uproszczenie i ułatwienie zrozumienia tworzonego przez nas kodu.
Podczas prezentacji, jak i po niej nie padło zbyt wiele pytań – moi „współstudiujący” nie byli zbytnio chętni rozmawiać ani pytać o jej treść. ;] Trochę dostało mi się za przedłużanie, ponieważ górnym limitem jest 20 minut, a przedstawienie wszystkich slajdów zajęło mi 22 minuty i 50 sekund. Na szczęście jednak prowadzący uznał chyba przedstawione materiały za wartościowe i udało się ponownie otrzymać piątkę, z minusem, żeby nie popaść w samozachwyt. ;]
Podsumowanie.
Prezentacje przygotowane, przedstawione, zostaje więc jedynie zabrać się za pisanie pracy. Mój plan jest taki, żeby zaimplementować wszystko do końca grudnia a w styczniu już szlifować samą pracę inżynierską. Czasu jest niemało, aczkolwiek dobrze wiem ile pracy będę musiał w to wszystko włożyć, dlatego nie zamierzam się obijać. Wyniki pracy jak i samą treść na pewno przedstawię Wam w stosownym czasie, także mam nadzieję, że będziecie cierpliwie czekać i dopingować mnie w pracy nad opisanym rozwiązaniem, za co z góry Wam dziękuję.
Warto przeczytać.
Trwa ładowanie…
Dobra to dyskusję zacznijmy od kwesti wzorca MVC – MVP.
Zgodze się, że typowa implementacja wzorca MVC w PHP’ie nie jest w pełni zgodna z zasadami. Warto byłoby się może jednak zastanowić, czy sposób w jaki implementuje większość FrameWork’ów ten wzorzec nie jest przypadkim uzasadniony.
Jak powinno wyglądać prawdziwe MVC?
Oryginalnie widok łączymy z modelem w celu aktualizacji danych. Tzn jeśli w danych modelu zajdzie zmiana to każdy widok podłączony do tego modelu powinien wyświetlić tą zmianę. Model taki był jednak stworzony dla aplikacji desktopowych, czyli języków posiadających cechę stanowości.
Odzwierciedlenia takiego stanu rzeczy w języku skryptowym jakim jest PHP jest w zasadzie niemożliwe, ponieważ tutaj każde żądanie (request) zwraca wyniki i następuje koniec pracy naszego programu. Nie ma możliwości aktualizacji danych w miarę zmiany. Oczywiście pomijam kwestię robienia ekstra zapytań ajax’em itp., bo wtedy i tak generujemy przecież nowe requesty.
Tak więc zastosowania prawdziwego MVC w PHP jest w zasadzie nierealne (przynajmniej dopóki ktoś nie wpadnie na pomysł zaimplementowania maszyny stanów).
Dlatego wydaje mi się bezsensowne twoje dążenie do odzwierciedlenia MVC zamiast MVP, bo prawodopodobnie skończy się to jakimś koślawym potworkiem.
Przenoszenie wywoływania metod z Modelu do widoku może skończyć się katastrofą (co za patos).
Bo w twoim modelu kontrolerem logiki aplikacji, który steruje Jest „Router”, „Controller” i „Viewer”. Każde ma możliwość wpływania na logikę działania.
Pomysł, żeby Viewer określał ile ma pobrać danych z modelu wydaje mi się nietrafiony i niefunkcjonalny.
Po to jest kontroller, żeby sprawdzić ile danych ma pobrać, jakie dane, czy użytkownik ma dostęp itp.
Zadaniem widoku jest dla mnie tylko kwestia zformatowania tych danych (np. ustawienia odpowiedniego formatu dat, liczb, kolorów itp.). To i tak dużo roboty, więc nie obciążałbym bardziej biedaczka.
Mówiłeś, że napiszesz komentarz, ale nie spodziewałem się aż takiej hojności z Twojej strony – postaram się zatem obronić swoje stanowisko. ;]
Konflikt MVC vs MVP wynika dokładnie z przyczyn które opisałeś. Nie znaczy to jednak, że w przypadku stron internetowych należy się starać odwzorować dokładnie ten sam sposób implementacji poszczególnych rozwiązań. Protokół HTTP jest bezstanowy, więc jak sam zauważyłeś nie da się utrzymać prawdziwego kontaktu użytkownika z naszą aplikacją. Można to symulować przez sesje, ale wydaje mi się, że to nie jest „rdzeń” problemu, z jakim próbują się zmierzyć aplikacje internetowe.
Wzorce projektowe to tylko sugestie dotyczące architektury aplikacji – zastosowane w różnych technologiach będą miały rożne implementacje. Jeśli zgodzisz się z takim stwierdzeniem, to kwestia poprawności MVC w PHP powinna być jasna – nie utrzymujemy stanu, bo nie mamy narzędzi, ale zachowujemy strukturę. Najgorsze jest to, że pomiędzy oboma wzorcami można się bardzo łatwo przełączać – wystarczy przesunąć zapytania do modeli do widoków a w modelach zrobić interfejsy wykonujące bezpośrednio „SQLe”. Zaimplementowanie „prawdziwego” MVC w PHP jest realne, tylko trzeba zrozumieć, że nie polega to na przeniesieniu idei znanych z desktopów do Internetu.
Różnica jest wyłącznie konceptualna – kontroler oczywiście ma służyć do sprawdzenia dostępu, odpowiednich ustawień oraz decyzji w kwestii jakie dane i gdzie zostaną wyświetlone. Uważam jednak, że to Widok decyduje, jak wyświetli te dane, dlatego powinien dostać nie „rybę” – gotowe kolekcje danych, ale „wędkę” – interfejsy modelu, dzięki którym np. różne szablony będą pobierały tyle danych i w taki sposób, jaki jest odpowiedni dla ich wyglądu. Framework, który wykonam będzie „obsługiwał” zarówno MVC, jak i MVP – jak zauważyłeś, na jednym ze slajdów umieściłem zdanie, że „i tak wszystko zależy od programisty”. Dlatego będę forsował MVC, pomimo tego, że i tak każdy „zrobi jak zechce”.
Zanim odpowiesz na moje stanowisko polecam lekturę dwóch wpisów z blogów branżowych:
http://www.zyxist.com/pokaz.php/rozwazania_o_wzorcu_mvc
http://tylczynski.pl/php/view-przyglupi-kolega-kazdego-mc
W komentarzu do wpisu na blogu tylczynski.pl wyraziłem się co najmniej niejasno, a wręcz przeczę temu, co teraz Tobie napisałem, dlatego potraktuj ten wpis jako „moje zdanie”.
Ono jest retoryczne tylko w przypadku gdy sądzisz że to co jest dostępne na rynku i jest rozwijane przez masę robotów (ajm sory deweloperów)
jest dobre
Rozumiem, że masz na myśli moje pytanie: „czy naprawdę komuś może się wydawać, że jest w stanie stworzyć coś lepszego?” – oczywiście pod wieloma względami jest dobre. Pomimo tego, że relatywnie trudno jest znaleźć framework który wpasowywałby się w naszą prywatną filozofię budowy tego typu aplikacji [przyznam, że pod tym względem symfony zyskało moje największe uznanie], to jednak nie deprecjonowałbym ich wkładu w rozwój technologii.
Wiem, że podana argumentacja jest bardzo bliska stwierdzeniu „miliony much nie mogą się mylić”, ale naprawdę, jeśli uda nam się „wdrożyć siebie” w taki sposób pisania stron internetowych, to tylko pogratulować. Ja jestem bardzo wybredny pod tym względem, więc niestety „i tak” muszę przetestować swój sposób, zanim stwierdzę, że jednak lepiej skorzystać z przetestowanego rozwiązania. Może tym razem będzie inaczej? ;]
Pingback: PHP: Sprawdzanie, czy plik został włączony do kodu. « Tomasz Kowalczyk