Zawartość
Zapytaj mnie, którego schematu użyć, a prawdopodobnie będę miał chwilę zrzędliwej starej kobiety i powiem ci, że wszystkie ramy są tak samo złe jak inne. Co nie znaczy, że wszystkie są dokładnie złe, ale w PHP mamy niewyobrażalnie dużą liczbę frameworków (zwykle cytowanych jako N + 1, gdzie N to liczba programistów PHP na świecie) i wszystkie prawdopodobnie miały sens osobie, która je wynalazła.
Wybór frameworka jest prawdopodobnie lepszy niż próba użycia tylko jednego frameworka, niezależnie od tego, co dokładnie próbujesz zbudować, ponieważ jest „najlepszy” (niezależnie od tego, jaki jest „najlepszy”). Ten wybór ofert ramowych oznacza, że możesz wybrać coś, co spełnia potrzeby projektu, a nawet może zostać udokumentowane. Struktury na każdej platformie naprawdę zapewniają strukturę, moduły i biblioteki wielokrotnego użytku i generalnie pozwalają uniknąć wszystkich nudnych i powtarzalnych zadań związanych z ciągłym budowaniem tej samej funkcjonalności. Na przykład podczas budowania CMS-ów coś powinno dla mnie przetworzyć i zweryfikować pola formularza; pozostawiony samemu sobie, mogę przegapić coś ważnego i wolałbym raczej zająć się elementami każdego projektu, które są różne, a nie te, które są za każdym razem takie same!
Struktury z pełnym stosem
Frameworki z pełnym stosem, takie jak Zend Framework, mogą być dobrym miejscem do rozpoczęcia pracy dla programisty bez dużego doświadczenia w architekturze. Daje dobrą strukturę, na której można zawiesić nową aplikację, a wokół niej jest dobry „ekosystem” - mnóstwo książek, samouczków, a także rozsądna dokumentacja. Jeśli próbujesz zbudować dużą aplikację, która będzie obsługiwana przez wiele osób, wówczas popularny, wszechstronny framework będzie prawdopodobnie dobrym wyborem, ponieważ będzie narzucać sporo struktury i być dobrze znany i zrozumiany.
Posiadanie struktury pomagającej w separacji jest zawsze dobre; na początku swojej kariery pracowałem z niektórymi bardzo młodszych programistów i próbowali nauczyć ich wzorca MVC (Model View Controller), który był wówczas stosunkowo nowy. Podjęliśmy decyzję o użyciu Smarty w warstwie widoku; częściowo po to, aby projektanci mogli łatwiej pracować z szablonami, a częściowo po to, aby ktoś podszedł do mojego biurka i zapytał „jak zrobić X ze Smarty?”. Mógłbym powiedzieć „nie rób X w widoku!” (dziewięć razy na 10, to była odpowiedź). Posiadanie frameworków pomaga nam znaleźć taką samą separację w innych częściach naszej aplikacji. Wiele z nich obsługuje integrację z warstwą szablonów, taką jak Smarty lub mój nowy ulubiony Twig, więc możesz zabrać te narzędzia ze sobą, niezależnie od wybranego frameworka.
Zmniejsz obciążenie
Istnieje wiele lżejszych frameworków niż Zend Framework, na przykład całkiem sporo pracuję z CodeIgniterem. Czy jest tak wszechstronny i solidny jak Zend Framework? Nie, nie jest. Ale jako platforma pomocnicza umożliwiająca szybkie tworzenie aplikacji jest przydatna. Ogólnie rzecz biorąc, frameworki z mniejszymi funkcjami pomocniczymi mogą być łatwiejsze do odnalezienia, ponieważ o wiele bardziej oczywiste jest, jak poszczególne elementy pasują do siebie. W nieznanym mi frameworku (dla mnie to prawie wszystko), to automagiczne bity utrudniają pracę i debugowanie.
To poczucie „zagubienia się w nowych ramach” jest nieuniknione i całkowicie frustrujące; nawet doświadczony programista czuje się jak nowicjusz, gdy nie wie, jak cokolwiek działa. Jeśli masz naprawdę pecha, wybrałeś framework, którego kanał IRC powie Ci, że również jesteś idiotą! To właśnie to bardzo negatywne doświadczenie początkowe zniechęca wiele osób do korzystania z nowego frameworka lub jego przyjęcia, a bardzo niewiele frameworków dobrze radzi sobie z pomaganiem nowym użytkownikom w pokonaniu tej początkowej przeszkody.
W PHP mamy również frameworki, które tak naprawdę nie są frameworkami w sposób, w jaki zwykle używam tego słowa. Mamy kilka uroczych ram składowych; kolekcje bibliotek zaprojektowanych do użytku na życzenie i do przyjemnego współdziałania, takie jak Zeta Components (wcześniej eZ Components) i Symfony Components (czy widzieliście ich stronę? Zdobywają nagrodę za najlepszą grafikę!). Najlepszą i najbardziej podkreśloną z nich jest oczywiście własna oferta PHP PEAR i PECL - w jakiś sposób zostają one zapomniane w tym nowym, wspaniałym świecie frameworków.
Microframeworks
Microframeworks to nowy trend w PHP; są to superlekkie produkty, które po prostu pomagają szybciej skleić elementy. Dobrym przykładem jest Slim, który jest bardzo szybki i prosty w użyciu oraz rozumie koncepcje RESTful. Opiera się na idei „tras”, które są wzorcami adresów URL. Rejestrujesz trasę i dajesz oddzwonienie, które powinno zostać wywołane, gdy zażąda się tego adresu URL.
Większość programistów PHP przyjmuje framework i trzyma się go, lub mogą używać jednego w pracy, a drugiego do swoich hobby lub projektów open source. Nie ma zgody co do „najlepszego” frameworka, więc wszyscy trzymają się tego, co wiedzą, a rezultatem jest równoległy rozwój ogromnej liczby frameworków! Uwielbiam mieć wybór do wyboru, ale czy wspomniałem, że wszyscy są tak samo źli jak inni?
Jeśli znasz Zend Framework, w końcu opisujesz siebie jako programistę Zend Framework; nie czułbyś się komfortowo pisanie w innym frameworku, dopóki nie miałbyś okazji się z nim uporać, i prawdopodobnie nie pamiętasz wielu nieprzetworzonych funkcji PHP, jeśli nie używasz ich często. Pomysł, że zostaliśmy programistami specyficznymi dla frameworka, pracującymi tylko na warstwach abstrakcji, jest trochę dziwny dla PHP. W końcu jest to język „rozwiązywania problemów z siecią”. Jest napisany w C i sam w sobie jest szybkim, lekkim językiem ... pod warunkiem, że nie będziesz czekać na uruchomienie dużego procesu ładowania frameworkowego! Z tego kontekstu wyłonił się Manifest MicroPHP, napisany przez człowieka, którego nazywamy Funkatron (chociaż tak naprawdę nazywa się Ed Finkler). Jest to seria stwierdzeń, które mówią, że można zbudować kilka współdziałających małych modułów, że większy nie znaczy lepszy i że tak naprawdę życie Javy jest zbyt krótkie - nawet jeśli jest napisane w PHP.
