Dlaczego laravel jest do rzyci #10
Conversation
|
|
| </ol> | ||
| <p> | ||
| Dlaczego w takim razie ktoś w ogóle używa Laravela? Z bardzo prostej przyczyny - Otwell zapewnia projektowi fenomenalny wręcz marketing, próg wejścia jest w zasadzie zerowy (najwyżej opakujesz kod proceduralny w statyczne metody), a do tego czas nas czasem goni... Co zrobić? Jak żyć? Nie używać Laravela do żadnych projektów, które potem będą musiały być przez dłuższy czas utrzymywane. Twoim celem jest zwiększenie sprzedaży piwa marki X w wakacje, wśród studentów? Zastanów się nad tym, czy nie byłoby warto użyć <a href="http://silex.sensiolabs.org/">Silexa</a> albo <a href="http://www.slimframework.com/">Slima</a>, a jeśli nie chcesz bądź po prostu musisz - to piszże w Laravelu.<br> | ||
| Nigdy, przenigdy, nie używaj Laravela do projektów, które będą miały być utrzymywane przez wiele lat. Słaba architektura Cię wykończy zanim zdąży Cię wykończyć brak dobrych testów jednostkowych. |
There was a problem hiding this comment.
Nie jestem przekonany do takich stwierdzeń. To mimo wszystko jest subiektywna opinia.
There was a problem hiding this comment.
Oczywiście, moja własna. Oparta na doświadczeniu w pracy (krótkiej, bo krótkiej) z Laravelem.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
wydaje mi się jednak że te detale jak najbardziej mogą być odpowiedzialne za wyłożenie aplikacji.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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.
| Ja, piszący te słowa, pracowałem przez dwa miesiące z Laravelem i moja do niego niechęć nie opiera się na zawiści wobec Taylora Otwella. | ||
| </p> | ||
| <p> | ||
| Laravel używa biblioteki o nazwie Eloquent, która ma być ORM, a tak naprawdę jest to Active Record. Doświadczenia z Eloquentem mam następujące: |
|
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. |
|
PR został w dużej mierze przebudowany. |
| <li>Alternatywą dla Dependency Injection są <a href="http://laravel.com/docs/5.1/facades">Fasady</a>. Ich nadużywanie prowadzi do sytuacji, w której trudno jest określić zależności danej klasy. Planowane jest wprowadzenie funkcjonalności pozwalającej na <a href="http://laravel.com/docs/master/blade#service-injection">dostęp do serwisów z poziomu template'ów.</a></li> | ||
| <li>Ze względu na Fasady w <a href="https://github.com/laravel/framework/blob/v5.0.32/src/Illuminate/Support/Facades/Facade.php#L42">produkcyjnym kodzie</a> znajdują się metody służące wyłącznie testowaniu.</li> | ||
| <li>Zapisywanie obiektu do bazy realizowane jest za pomocą <a href="https://github.com/laravel/framework/blob/v5.0.32/src/Illuminate/Database/Eloquent/Model.php#L1185">statycznej metody save()</a>, której mockowanie w testach jednostkowych jest mocno utrudnione.</li> | ||
| <li>Przykładem nadużywanie statycznego dostępu jest klasa odpowiedzialna za <a href="https://github.com/laravel/framework/blob/v5.0.32/src/Illuminate/Support/Str.php">operacje na ciągach znaków</a>.</li> |
There was a problem hiding this comment.
@efik - poprawione. Ja mam tendencję do pisania w taki sposób jak oryginał był napisany ;)
|
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. |
| </ul> <!-- cd-faq-group --> | ||
| </ul> | ||
| <ul id="frameworki" class="cd-faq-group"> | ||
| <li class="cd-faq-title"><h2>Frameworki</h2></li> |
There was a problem hiding this comment.
To nie powinno być "Wady i zalety wybranych Frameworków" ?
There was a problem hiding this comment.
Nie koniecznie - może o innym fw będziemy pisać same zalety :]
There was a problem hiding this comment.
Nie ma frameworków, które mają same zalety :D
|
Myślę, że warto byłoby też dodać przy każdym punkcie, których wersji Laravela dotyczy. |
|
@norzechowicz - jest wersja. |
|
Najwyższy czas :D |
|
Jo, już zerowe jest moje zainteresowanie tymi problemami :D aż się zdziwiłem, że takie coś jeszcze w ogóle wisiało. Jak to się człowiek uspokoił I nabrał dystansu przez 5 lat :D |
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.