Dlaczego laravel jest do rzyci

[iwankgb]

Zgodnie z prośbą, którą Leszek złożył na fejsie: oto i pull request do PHPersowego FAQ tłumaczący dlaczego Laravel to zło.

[adampiotrowski]

👍

[norzechowicz]

Nie jestem przekonany do takich stwierdzeń. To mimo wszystko jest subiektywna opinia.

[iwankgb]

Oczywiście, moja własna. Oparta na doświadczeniu w pracy (krótkiej, bo krótkiej) z Laravelem.

[norzechowicz]

No właśnie, tylko że FAQ PHPers to raczej nie są doświadczenia i wnioski jednej osoby a raczej całego community. Poza tym ja się z tym stwierdzeniem nie zgadzam, framework to detal a detale nie mogą wyłożyć całego projektu.

[iwankgb]

Zapraszam serdecznie do przedstawienia wniosków innych członków społeczności. Na tyle konkretnych, że da się je ubrać w formę PR.
Z resztą Twojej wypowiedzi się nie zgadzam.

[kallosz]

wydaje mi się jednak że te detale jak najbardziej mogą być odpowiedzialne za wyłożenie aplikacji.

[norzechowicz]

To czy mogą czy nie mogą jest dyskusja na osobny wątek.
Jako społeczność nie powinniśmy przyjmować żadnego stanowiska a zamiast tego obiektywnie pokazać wady (których jest więcej) i zalety (których praktycznie nie ma).
Załóżmy, że ten PR zostanie zmergowany w formie bez personalnych wniosków. Dzięki temu damy możliwość zrobienia PR'a z zaletami korzystania z tego "frameworka", dajmy ludziom wybór na podstawie rzetelnych informacji zamiast narzucać im własne zdanie.

[iwankgb]

@norzechowicz - co jest osobistym wnioskiem wg Twoich kryteriów? Jeśli to co piszę opieram o własne doświadczenie, to w zasadzie wszystkie te wnioski są mniej lub bardziej osobiste.

[norzechowicz]

Słaba architektura Cię wykończy zanim zdąży Cię wykończyć brak dobrych testów jednostkowych.

To jest osobisty wniosek w dodatku niesłuszny.

[norzechowicz]

W zasadzie to nie hejtujemy bo nie można nazwać hejtem powiedzenia, że białe jest białe a czarne jest czarne.

[iwankgb]

Wpis na temat Laravela ma charakter popularyzatorski i utrzymany jest w lekkim tonie ;)

[norzechowicz]

Wpis na temat Laravela powinien jednak dostosować się do pozostałych wpisów.

[iwankgb]

Być może znaczy to tyle, że wpis ten w takiej formie nie nadaje się do tego FAQ.

[iwankgb]

Dobra - ponieważ ten wpis ma zasadniczo inny charakter, to proszę o jakieś bardziej szczegółowe informacje czego oczekujecie. Od koncepcji listy nie odejdę, bo pozwala ona krótko i zwięźle przedstawić zarzuty/wady/zalety.
Ma być na bardo poważnie i w stylu manuala?

[iwankgb]

@efik - wydaje mi się, że lepiej odsyłać do fejsa w "przypisach" niż po prostu wrzucać linki tamże. Głównie dlatego, że tam znajdzie się zawsze (albo prawie zawsze) jakiś flejm, a zaproponowana przeze mnie forma wskazuje na słabości i ewentualnie odsyła do dyskusji na ich temat.

[norzechowicz]

Też nie jestem przekonany do wrzucania linków do grupy na fejsie, lepiej wyciągnąć najlepsze kawałki, zapytać autorów o zdanie i zmontować z tego wpis do FAQ.

[leafnode]

Problem z linkowaniem do fejsa jest taki, że dyskusje na fejsie mogą zniknąć dosyć łatwo i szybko.

[norzechowicz]

To w sumie nie jest istotne.

[iwankgb]

IMHO jest - fakt, że pracowałem z Laravelem pozwala mi oceniać jego słabości od środka, a nie tylko przez pryzmat chujowej architektury.

[norzechowicz]

Tylko, że FAQ PHPers to nie "prywatne odczucia Maćka" a raczej źródło informacji, bez sprecyzowanego autora.

[norzechowicz]

W sumie zmieniłbym formę wypowiedzi, zamiast pisać to jako rozmowę z czytającym IMO bardziej merytocznie byłoby po prostu zrobić listę ułomność Laravela.

[iwankgb]

Tam jest dość konkretna lista ułomności. Forma ma jeden cel - ułatwić użytkownikowi zrozumienie mojego przekazu i uważam, że ją to usprawiedliwia.

[norzechowicz]

Forma dla całego FAQ powinna być spójna.

[adampiotrowski]

@iwankgb Nie, to cały czas dość mocno personalna wycieczka po Laravel. Fakt że podajesz mocne (i pewnie dla większości wystarczające) argumenty, ale jak dla mnie forma nie jest odpowiednia. Widziałbym to raczej na jakimś blogu.

Moim zdaniem każdy powinien wyciągnąć odpowiednie wnioski, programowaniem raczej nie zajmują się kompletni idioci bez zdolności analitycznych ;), a zadaniem FAQ jest tak naprawdę wskazanie odpowiednich źródeł. Wydaje mi się że lepiej tutaj sprawdzi się forma wypunktowania konkretnych ułomności z bardzo konkretnymi przykładami.

Nie leciałbym tutaj w coś takiego jak napisał Ocramius, nie ma sensu duplikować, ale na pewno warto zalinkować z wyjaśnieniem kim on jest i czym się zajmuje. https://gist.github.com/anonymous/8565929

[llubosz]

Nie jest, a implementuje

[llubosz]

W jakiej przyrodzie i skoro Ty nie rozumiesz, to być może ktoś inny zrozumie

[llubosz]

Hm, chciałem się odnieść do szczegółów, ale chyba to bez sensu. Wydaje mi się, że wpis jest bardzo subiektywny, co w FAQ nie powinno się znaleźć. Laravel nie jest szczytem osiągnięć architektury oprogramowania, ale w ten sam sposób powinniśmy opisać każdy przypadek użycia PHP analizując jego wady i zalety. Imho - bez sensu.

[iwankgb]

PR został w dużej mierze przebudowany.

[iwankgb]

@efik - poprawione. Ja mam tendencję do pisania w taki sposób jak oryginał był napisany ;)

[iwankgb]

W trakcie rozmowy z @flashek na #mikolow powstała koncepcja omówienia tego (i innych podobnych wpisów) na PHPConie. Jak mają wyglądać, jak ma wyglądać proces decyzyjny dotyczący odrzucania bądź akceptowania takich zmian itp, itd.

[norzechowicz]

To nie powinno być "Wady i zalety wybranych Frameworków" ?

[leafnode]

Nie koniecznie - może o innym fw będziemy pisać same zalety :]

[norzechowicz]

Nie ma frameworków, które mają same zalety :D

[norzechowicz]

"Laravel - Wady" ?

[leafnode]

👍 - wady, zarzuty, cokolwiek informującego, że to nie jest opis całego fw, a tylko odpowiedź na pytanie "co wy się tak tego lrv czepiacie"

[norzechowicz]

To na pewno jest wada? Doctrine też pozwala wykonać query żeby zwróciło tablicę lub obiekty. Fakt, to powinna być opcja i hydrator a nie builder osobny ale samo istnienie dwóch builderów nie wydaje mi się jakoś tragiczne.

[iwankgb]

Uważam, że to wada, bo zapytania są takie same bez względu na formę, w której zwrócone są wyniki.

[norzechowicz]

Co z tego? Doctrine też generuje takie same zapytanie niezależnie jaką strategię hydracij wybierzesz.

[iwankgb]

Norbercie, zapytania z query buildera ORMowego i DBALowego są zupełnie inne (a o takiej różnicy właśnie mówimy w przypadku Laravela - "ORM" i surowe zapytania). Zauważ też, że żaden z builderów doctrine'owych nie zwraca encji - encje może zwrócić co najwyżej repozytorium (w przypadku Laravela jest to odpowiedzialność query buildera - np. https://github.com/laravel/framework/blob/v5.0.32/src/Illuminate/Database/Eloquent/Builder.php#L75). Bardziej sensownie będzie chyba faktycznie położyć akcent w tym miejscu: zadaniem query buildera jest budowanie zapytań, a nie hydrowanie obiektów.

[norzechowicz]

https://github.com/laravel/framework/blob/v5.0.32/src/Illuminate/Database/Eloquent/Builder.php to nie jest query builder - to jest jakiś tam Eloquent builder. To jest https://github.com/laravel/framework/blob/v5.0.32/src/Illuminate/Database/Query/Builder.php query builder i on faktycznie nie powinien wykonywać query tylko je budować (tworzyć -> uzupełniać -> zwracać).

Co do Dotrine to nie mieszajmy w to DBAL'a. Te przypadki nie są w ogóle do siebie podobne. Encji nie zwraca repozytorium tylko hydrator wywołany na query podczas wykonywania getResults. Samo query natomiast można zbudować QueryBuilderem. Jednak niezależnie od tego jaką strategię hydracji wyników wybierzesz samo zapytanie do bazy się nie zmieni, hydracja wykonuje się na pobranych danych a nie na zapytaniu.

[iwankgb]

Norbercie - nie "jakis tam", tylko jeden z dostępnych w projekcie i ściśle (oraz bardzo źle) połączony z drugim. Zgadzam się w pełni z tym, że należy to zdanie przeformułować i położyć nacisk na to, że jeden z nich pełni rolę repozytorium. Pasuje?

[norzechowicz]

Nie pełni roli repozytorium. Właśnie problem w tym, że nie wiadomo jaką "to coś" rolę pełni albo jaką próbuje pełnić. Wygląda mi to na coś w rodzaju Data Access Object, który wewnętrznie korzysta z QueryBuilder, który z kolei nie jest nawet builderem, po prostu implementuje fluent interface co jeszcze nie robi z niego buildera. Swaglor widzę nie tylko Fasady od Proxy nie odróżnia ale też myśli, że jak coś zwraca w każdej metodzie $this to jest builderem.

[norzechowicz]

Znajdowały się w nim pewne...

Skoro się już nie znajdują to po co o nich pisać?

[iwankgb]

Bo daje to pojęcie o jakości projektu.

[norzechowicz]

Gdyby PR nie został zmergowany można by było użyć takiego argumentu.

[iwankgb]

Nie piszę, że Taylor nie merdżuje PRów. Zwracam uwagę na to, że nawet te fragmenty kodu, które wydają się być dość sensowne mają zwyczaj być niedopracowane.

[norzechowicz]

Ale po co w testach jednostkowych mockować save? To już mi śmierdzi testami integracyjnymi a nie jednostkowymi. Jeżeli te modele AR potraktujesz jako DAO, tego problemu nie ma.

[iwankgb]

Np. w celu zbudowania złożonych relacji w bazie; musisz zapisać jeden obiekt, żeby inny mógł być w relacji do niego.

[norzechowicz]

I to jest Twoim zdaniem testowane w testach jednostkowych?

[iwankgb]

Przede wszystkim uważam, że nie jest to przedmiotem tego PRa. Będę bardzo zobowiązany jeśli zechcesz wrócić do meritum.

[norzechowicz]

Nie możesz nazwać wadą frameworka, to że źle go używasz - to jest meritum. O ile sama statyczna metoda ::save jest zła tak argumentacja w tym przypadku dlaczego tak jest też nie jest o wiele lepsza.

[iwankgb]

Norbercie, nie uważam, żebym go źle używał. Jeśli chcesz prowadzić dyskusję na ten temat, to zapraszam: mail, Facebook, Twitter. Ja się z Tobą po prostu nie zgadzam i nie zamierzam zmieniać tego fragmentu.

[norzechowicz]

Masz takie prawo, ja natomiast nie zgadzam się z argumentacją jaką przedstawiłeś, jest niejasna, najprawdopodobniej problemy, które napotkałeś są wynikiem braku odpowiedniej warstwy abstrakcji co uniemożliwiło Ci napisanie odpowiednich testów - moim zdaniem to dyskwalifikuje ten wpis.

[iwankgb]

Norbercie, warstwa abstrakcji (czy raczej to co sie za nia kryje) tez musi mieć jakieś testy. Prędzej czy później dojdziesz do momentu, w którym zawolasz persist() albo save(). Oczywiście - może być to test funkcjonalny (tak by pewnie sugerowała Clean Architecture).
Uważam wszakże, ze pisanie zawsze kodu doskonale oderwanego od frameworka, jest działaniem niepotrzebnym. W pewnych sytuacjach wręcz niemożliwym (sam wspominales o CA i Laravelu w ostatni poniedziałek w Gdańsku)
W imię zasad to Franz Maurer kolegę zastrzelił i nic dobrego z tego nie wyniknelo ;)

Pozdrawiam/Regards,
Iwan.

[norzechowicz]

https://github.com/laravel/framework/blob/5.1/src/Illuminate/Support/helpers.php - to też bym gdzieś wrzucił

[iwankgb]

Dorzuciłem. Bo jest ładniejsze niż się na pierwszy rzut oka wydaje.

[norzechowicz]

Myślę, że warto byłoby też dodać przy każdym punkcie, których wersji Laravela dotyczy.

[iwankgb]

@norzechowicz - jest wersja.