Czy sensowne jest unikanie frameworka przy tworzeniu dużej aplikacji internetowej za pomocą PHP?

Jako programista aplikacji internetowych PHP od kilku lat mam swój udział w MVC i frameworkach. Na początku myślałem, że to najlepsza rzecz od czasu krojonego chleba; wszystko wydawało się bardzo łatwe do wdrożenia.

Teraz jednak wydaje się, że im bardziej złożona jest aplikacja, tym trudniejsze jest środowisko, więc muszę opracować obejścia, aby je pokonać. Takie obejścia są zwykle dość zniechęcające i skomplikowane, ponieważ muszę zagłębić się w podstawowy kod frameworka i wprowadzić zmiany, aby działał tak, jak chcę.

Na przykład w jednym z moich projektów, w których używam Slim (C) + Idiorm (M) + Twig (V) (co moim zdaniem jest bardzo elastyczne), muszę utworzyć niestandardową funkcję tylko po to, aby wyświetlać dane dynamiczne w szablonach nadrzędnych; bez frameworka mógłbym po prostu wykonać mysql_query () w dołączonym pliku.

Ok, frameworki są fajne, jeśli tworzę prostą stronę internetową z profilem firmy; Mogę po prostu ubić trochę kodu w ciągu jednej nocy i zwykle są gotowe do rana, a ilość dobrych praktyk kodowania i wzorców projektowych, których się z nich nauczyłem, jest bardzo cenna.

Ale tak naprawdę, w przypadku złożonej aplikacji internetowej, takiej jak zintegrowany internetowy system zarządzania szkołami, ramy zwykle przeszkadzają w procesie biznesowym, jak w powyższym przykładzie.

Więc moje pytanie brzmi: czy mogę wrócić do podstaw i użyć standardowego kodu PHP i bibliotek do wykonania mojego następnego projektu, w którym mogą istnieć biblioteki i biblioteki gazillionowe, pod warunkiem, że mogę w wystarczającym stopniu korzystać z dobrych praktyk kodowania i stosować rozsądne wzorce projektowe jak MVC? Mój zespół programistów jest dość mały: tylko 2 programistów i 1 projektant. Drugi programista zgadza się z moimi przemyśleniami powyżej.

Moje doświadczenie jest zupełnie przeciwne do twojego. Podczas wykonywania drobnych, szybkich rzeczy framework może trochę „przeszkadzać”, ponieważ musisz ułożyć swój kod w określony sposób i dokładnie przemyśleć sprawy przed kontynuowaniem. Skacząc prosto do niego mysql_query, możesz uruchomić swój prototyp i działać znacznie szybciej.

Ale dla dużych, złożonych stron, starannie układanie kod i naprawdę myśleć o tym, jak napisać kod jest niezwykle ważne, jeśli chcesz witryny, która będzie w utrzymaniu w przyszłości.

W szczególności dodawanie mysql_querywywołań do losowych części cyklu strony jest ogólnie bardzo złym pomysłem. Możesz mieć jeden tutaj i jeden na początku i to nie jest wielka sprawa, ale wkrótce dostałeś tuzin rozsianych po całym miejscu i zastanawiasz się, dlaczego strony renderują się po 3 sekundach. Lub zmienisz schemat i pozornie niepowiązane fragmenty strony zepsują się z nieznanych przyczyn.

Moim zdaniem ramy powinny być używane tylko wtedy, gdy ułatwiają ci proces programowania, a nie są uciążliwe. Nie ma nic złego w nieużywaniu frameworka lub budowaniu własnego, szczególnie w przypadku małych projektów.

Oczywiście nadal będziesz musiał zwracać uwagę na strukturę i aspekty bezpieczeństwa, ale biorąc pod uwagę, że używasz ram od wielu lat, prawdopodobnie już znasz te aspekty na wylot.

W przypadku większych projektów zgadzam się z innymi, co oznacza, że ​​użycie frameworku będzie prawdopodobnie najlepszą opcją na dłuższą metę.

Moje doświadczenia z „frameworkami” po stronie serwera były dość nieprzyjemne, na przykład:

A) Piekło w pliku jar, w którym frameworki kolidują ze sobą lub z serwerem aplikacji dla wzajemnie niekompatybilnych wersji rzeczy, których nie chcesz i nic nie wiesz, i nie są w stanie dyktować, ponieważ uniemożliwi to wdrożenie na wiele serwerów.

B) Katastrofalna eksplozja najprostszego stworzenia obiektu w tysiące niepotrzebnych wykonań SQL.

C) Dziwne przekonanie, że kodowanie 100 linii XML jest w jakiś sposób łatwiejsze lub bardziej niezawodne niż kodowanie 2 linii Java.

D) Konieczność napisania setek wierszy całkowicie niepotrzebnego POJOS po stronie serwera w celu odwzorowania na obiekty po stronie klienta w innym, lub czasem w wielu innych językach (C # JS itp.)

E) Brak pojęcia, co tak naprawdę się wydarzyło, gdy otrzymasz 30-poziomowy ślad głębokiego stosu, który nawet nie zawiera wiersza kodu użytego do wywołania frameworka.

Bądź renegatem, pisz własne ramy ... nie pożałujesz, dopóki planujesz najpierw wyeliminować wszystkie niepotrzebne rzeczy, które inni oszukiwają cię do myślenia, że ​​potrzebujesz. Zrozumiesz to wszystko, będzie on wysyłany w Kb zamiast Mb i prawdopodobnie będzie „działał wszędzie”, co było jedną z podstawowych zasad Javy, prawda?

Spróbuj pomyśleć w ten sposób „po co mi to ... czy to po prostu, aby utrzymać ramę szczęśliwy?” .. Jeśli tego nie potrzebuję, to czego jeszcze nie potrzebuję?

Deweloperzy Django przygotowali prezentację, której nie mogę teraz znaleźć, ale mówią o „dolinie wydajności”, w której ramy zwiększają produktywność.

Zakładając, że nie masz wiedzy na temat frameworka, kiedy zaczynasz projekt, twoja produktywność początkowo będzie bardzo niska - będziesz uczył się konwencji frameworku, a nie idiomu języka (który, mam nadzieję, już znasz).

Po niedługim czasie zapoznasz się z konwencjami i tutaj naprawdę świecą ramy - nagle Twoja produktywność przebija się przez dach, a ty rozwijasz się z niesamowitą szybkością.

Ostatecznie jednak projekt stanie się tak duży, że ramy będą bardziej ograniczeniem niż dobrodziejstwem, a ty zobaczysz, jak poradzisz sobie z ramą, aby spróbować zaimplementować niektóre funkcje.

W prezentacji wspominają, że oczywiście, jeśli znasz już konwencje ram, wówczas projekty mniejszych rozmiarów nie mają początkowej przeszkody w wydajności.

Tak więc, w przypadku małych projektów (z mojego doświadczenia, wszystko poniżej ~ 500 godzin) twoja wydajność w ramach będzie prawdopodobnie większa niż wydajność bez. Gdy osiągniesz określony próg (od 500 do 800 godzin, IME), wtedy zaczynasz zdawać sobie sprawę, że istnieją ograniczenia tego, co może zaoferować środowisko.

Mając to na uwadze, frameworki oferują znacznie większą korzyść niż tylko wydajność - frameworki takie jak Symfony lub Django lub (zakładam, że) Railsy zapewniają konwencję, która pozwala zespołowi dynamicznie elastycznie, a także pozwala klientom lub właścicielom produktów na zmianę personelu bez wymagania nowy zasób, aby całkowicie ponownie nauczyć się nowego systemu - jeśli znają konwencję ramową i ta konwencja została zastosowana, początkowo będą znacznie bardziej produktywni niż w innym przypadku.

Dobrze zaprojektowane środowisko powinno być dla programisty pomocą, a nie przeszkodą. Jeśli użyty framework jest zbyt duży, sugerowałbym spojrzenie na inny framework. Każdy ma swój własny styl kodowania oraz swoje zalety i wady.

Powiedziawszy to, środowisko Zend wydaje się być obecnie bardzo popularne i szczerze? Czasami próbuję zrozumieć, dlaczego. W przeszłości musiałem z tym pracować i nie podobała mi się ani trochę jego architektura. Klasa Zend_Form jest absurdalnie przeprojektowana, jej system dekoratorów jest całkowicie okropny w użyciu, a dekoratorzy wiążą formy z widokami, łamiąc fundamentalną koncepcję OOP, mówiącą, że przedmioty powinny być luźno sprzężone. Ma również dużo kodu zaimplementowanego jako Singletones (które są złe z powodów, które są dobrze udokumentowane, więc nie powtórzę), a obiekt rejestru przyczynia się również do zachęcania do niechlujnego stylu kodowania.

Słyszałem, że Zend Framework 2 (obecnie w fazie beta) jest znacznie lepszym produktem, ale zły smak Zend 1 pozostawiony w moich ustach oznacza, że ​​nie spieszy mi się go wypróbować.

Mimo to w tym momencie po prostu gadam. :) Istnieje wiele ram, każdy z ich zaletami i wadami, sugerowałbym ocenę kilku z nich.

To, co opisujesz, w przeszłości nazywano „złożonością wywołaną abstrakcją”. Jedyny artykuł na temat zarządzania nią to: Zarządzanie złożonością wywołaną abstrakcją przez Davida Keppela. Keppel sugerowałby, że ramy mają projekt, który powoduje złożoność wywołaną abstrakcją.

Praca z ramami pomaga przyspieszyć rozwój, nie odkrywając koła . Framework zapewnia również narzędzia, które pomogą ci właściwie zaprojektować aplikację (ale nie powstrzymuje cię to od podejmowania złych decyzji projektowych, np. Dostępu do bazy danych bezpośrednio z widoku).

Czasami, gdy potrzebujesz niestandardowej funkcjonalności, jej prawidłowe napisanie może potrwać dłużej. Ale jeśli ciągle hakujesz i znajdujesz obejścia, pracujesz wbrew frameworkowi lub frameworkowi nie odpowiada twoim potrzebom.

Najważniejsze jest to, że użycie dużego frameworka do prostych projektów (np. Wyświetlanie kilku pól z bazy danych) może czasami być nadmierne. W przypadku dużych lub złożonych projektów użyj ram.

Istnieje wiele aspektów pisania własnego kodu w porównaniu do korzystania z frameworka:

Wielkość, podstawowa wiedza i doświadczenie zespołu, z którym pracujesz : jeśli nigdy nie korzystali z frameworka lub nie mieli pojęcia, jak zaprojektować aplikację, lepiej jest to z dobrze udokumentowanym frameworkiem z dużą ilością przykładów i przekonać się, że przyspieszasz je w górę.

Rozmiar aplikacji : nigdy wcześniej nie wiadomo, jak będzie używana. Więc lepiej bądź przygotowany na rozwój i zmianę. Czy Twój framework, który chcesz kodować w ciągu jednej nocy, może rosnąć wraz z potrzebami zarządzania? Zmień typy pól w DB, a wdrożenie zajmie minutę lub dzień, o to mi chodzi.

Przygotowanie : Jeśli używasz frameworka, możesz zacząć projektować aplikację zamiast kodować jej rdzeń, użyj takiego, w którym bezpieczeństwo i wdrożenie są ważnymi częściami, a to zajmuje tyle czasu. Każdego razu.

Zawsze kłócę się z „kierownictwem”, aby użyć Symfony2, ponieważ jest to środowisko programistyczne. Kierownictwo uważa, że ​​jest za duży, będzie to kosztować pieniądze i zniechęci programistów, ponieważ krzywa uczenia się jest stroma.

Szkielety będą nadal używane w każdym języku współczesnym, szczególnie w dużych projektach. Im większy projekt, tym ważniejsza jest struktura, więc wiesz, gdzie jest logika wszystkiego, a każda funkcja ma podobny układ. Ułatwia modyfikowanie projektu i uczy się go łatwiej, gdy wiesz, gdzie szukać dostępu do danych lub całej prezentacji lub gdzie zarządza się regułami biznesowymi.

Konieczne jest jednak wybranie frameworka, który pasuje do projektu, rozwiązanie korporacyjne wymaga frameworku przystosowanego do potrzeb przedsiębiorstwa. To jest problem, na który natkniesz się podczas korzystania z PHP. Wiele (większość) frameworków nie jest przeznaczonych do użycia na dużą skalę, ale działają one dobrze w przypadku mniejszych witryn osobistych. W przypadku czegoś takiego, jak wspomniany system zarządzania szkołą, będzie on wymagał bardziej solidnych ram i znalezienie odpowiedniego szkieletu w PHP może zająć trochę czasu.