5 of the Common Mistakes Made by Laravel Programmers
Development / Laravel

5 najczęstszych pomyłek programistów w Laravel 5

W trakcie rekrutacji pracowników do Devpark, nie raz spotykamy się u wielu kandydatów z tymi samymi pomyłkami w kodzie aplikacji budowanych w oparciu o Laravel 5. Poniższy artykuł opisuje te najczęściej spotykane i daje wskazówkę, gdzie można szukać właściwego podejścia. Specjalnie nie opisujemy tutaj rozwiązań – artykułów na ten temat powstało już wiele, ważniejsze jest ich uświadomienie i zapoznanie się z nimi.

#1 Walidacja w kontrolerach
Często spotykaną praktyką jest umieszczanie walidacji parametrów przychodzących w żądaniu do serwera w metodach kontrolera. O ile w Laravel 4 było to zrozumiałe, o tyle Laravel 5 wprowadził Form Request, który jest właściwym miejscem do walidacji.

Każda klasa posiada przynajmniej metodę  rules() którą możemy wykorzystać.
Poniższy link prowadzi do obszernego artykułu, opisującego w jaki sposób prawidłowo zaimplementować walidację poza kontrolerem.

laravel-5.0-form-requests

#2 Gruby kontroler

Jednym z najpoważniejszych błędów jest umieszczanie sporej części logiki biznesowej w warstwie kontrolerów. Wynika to najczęściej z braku doświadczenia i pomysłu na to, co zrobić z kodem, który nie pasuje do umieszczenia w modelu Eloquenta. Zazwyczaj ląduje on w kontrolerze.
Istnieje wiele metodyk jak rozwiązać problem zbytnio rozbudowanych kontrolerów. W ostatnim czasie dość popularne stały się Repositories. Należy je jednak stosować z rozwagą i świadomością do czego służą. Jeśli nie planujesz zmieniać sposobu w jaki łączysz się z bazą czy też np. przenosić kod do innego frameworka – w naszej opinii nie mają sensu.

W Devpark praktykujemy podejście, aby do bazy maksymalnie wykorzystywać możliwości klasy Eloquent, a logikę nie związaną bezpośrednio z bazą danych umieszczać w tzw. Managerach bazujących na wzorcu Fasada.
Dzięki takiemu podejściu kod znajdujący się w kontrolerze upraszcza się do wywołania metody z managera, przekazaniu jego rezultatów do widoku bądź w postaci np. JSON jako odpowiedź na żądanie. Klasy managera umieszczamy natomiast w katalogu Services.

Przykład jak wygląda kontroler, z którego logika biznesowa została przeniesiona co wspomnianych klas managerów. Przed refaktoryzacją, metoda ta posiadała 200 linii kodu i ciężko było się odnaleźć, która część była za co odpowiedzialna.

controller

Poniżej kod jednej z metod wywołanych w powyższym kontrolerze. Od razu widać, że także tutaj poszczególne elementy kodu zostały wydzielone do odpowiednich metod, dzięki czemu to co się dzieje jest dość klarowne.

manager

#3 Kod w widokach

Jedną z złych praktyk jest stosowanie kodu php bezpośrednio w widokach, w celu pobrania lub wyliczania jakiejś zmiennej, nie przekazanej w kontrolerze. Przykładem tego może być pokazanie avatara zalogowanego użytkownika we współdzielonym layoucie strony. W Laravel 5 istnieje do tego wyspecjalizowane narzędzie jakim jest ViewComposer. To w nim właśnie należy umieścić zainicjowanie zmiennej w odpowiednią wartość i przekazanie jej do widoku. Jest to także sposób, aby przekazać wartość do wielu widoków, które tę wartość mają współdzielić.Więcej na temat tego przydatnego narzędzia można poczytać bezpośrednio w dokumentacji:

https://laravel.com/docs/5.3/views

#4 Skrypty js i stylów w public

Dość utrudniającą sprawą dla opanowania skryptów JavaScript oraz CSS jest umieszczanie ich kodu bezpośrednio w /public. Laravel od wersji 5 posiada wbudowany GULP oraz Elixir wspomagający jego konfigurację. Kod Javascript jak i style powinny zostać umieszczone w folderze /resources/assets/ js lub sass. Dzięki temu – skrypty te możemy podzielić na odpowiednio nazwane pliki, które bardziej będą obrazować przynależność danego kodu, natomiast dzięki GULP wszystkie te pliki możemy odpowiednio złączyć np. do jednego pliku, co przyspieszy ładowanie skryptów do przeglądarki. Jedno z przykładowych podejść można zobaczyć na tej stronie:

run-gulp-tasks-in-laravel-easily-with-elixir

Jest to jednak tylko jedno z wielu możliwych sposobów wykorzystania tego potężnego narzędzia. Zachęcamy do szerszej lektury.

#5 Wykorzystanie Fasad Laravela poza kontrolerami i middleware
O ile w obrębie kontrolerów i middleware wykorzystanie Fasad (A co za tym powiązane bezpośrednio IoC Laravela) jest całkowicie zrozumiałe (są one nierozerwalną częścią frameworka i nieprzenoszalną), to poza kontrolerami nie powinno mieć to miejsca. Wszędzie poza kontrolerami należy wykorzystywać Dependency Injection. Ułatwia to nie tylko kontrolę nad kodem, poprawia jego skalowalność, ale także w dużej mierze upraszcza pisanie testów i zrozumienie kodu.
p.s. Fasada Laravela to coś stricte związanego z tym frameworkiem i nie należy jej mylić z wzorcem projektowym fasada