Czesć, czy osobie która zna Laravel trudno będzie przesiąść się na Symfony, oraz ile czasu może to zająć ?
0
0
Zależy. Jeśli jesteś prosem to cieżko nie ale bedziesz się wkurzał, że przecież w laravelu coś da się zrobić jedną linią a tutaj musisz pisać całą metodę by efekt był ten sam. Testy też są dużo gorsze w syfie niż larvie, tzn nie ma tylu helperów i trzeba pisać wszystko po swojemu.
1
Kiedyś się przejmowałem bo podobno laravel to taki amerykański produkt marketingu ale niezbyt dobrze napisany. Symfony miało być pięknym state of art. No ale potem przychodzi rzeczywistość i nikt z biznesu nie daje jebania o to ile reguł clean code złamałeś jeśli pracujesz nad crudem od miesiąca.
Pamiętam jak ten twórca Laravela wozil się Ferrari i jak to tak programista w takim aucie przecież powinien mieć co najwyżej hybrydową Toyotę.
1
Z mojego doświadczenia - w Symfony jest więcej projektów typu DDD.
W SF masz Data Mapper a nie Active record.
IMHO Active Record wydaje się być prostszy, szczególnie jeśli pod spodem masz na encje nie tylko bazę danych a jeszcze np. jakiegoś Redisa.
Same configi w SF w porównaniu do Laravel to oranie pola motyką.
Zrób sobie jakiś prosty projekt w SF z czytaniem dokumentacji i sam porównaj.
1
Podchodząc od strony SOLID'a, jeśli kładziesz tak duże rozróżnienie na framework, to znaczy że Twoja warstwa biznesowa jest niepoprawnie oddzielona od biblioteki.
Ale biorąc pod uwagę że praktycznie 99% projektów ma ten problem, to Laravel jest moim zdaniem bardziej opinionated, łatwiej w niego wejść i zacząć rzeczy, sporo jest out of the box, ale jak już wejdziesz to ciężej złamać zależność na niego, niż na takie Symfony.
2
@Riddle: w w laravelu nie robi się ddd a do solida podchodzi z przymróżeniem oka. Robienie ddd w laravelu to jak wzięcie piłki do piłki nożnej i granie nią w koszykówkę, no da się ale jednak na siłę i bez korzystania z zalet tej piłki tam gdzie te zalety działają.
0
@Riddle: w w laravelu nie robi się ddd a do solida podchodzi z przymróżeniem oka. Robienie ddd w laravelu to jak wzięcie piłki do piłki nożnej i granie nią w koszykówkę, no da się ale jednak na siłę i bez korzystania z zalet tej piłki tam gdzie te zalety działają.
Przez początkowy development pewnie tak. Ale im dłużej rozwijasz taki projekt, tym bardziej zalety DDD i SOLID zaczną wygrywać, i tym bardziej to co wcześniej było out-of-the-box staje się wish-I-never-added-this. Spróbuj tak rozwijać aplikacje 10 lat i powiedz wtedy które z tych podejść jest lepsze. spoiler alert - loose coupling na framework wygrywa everytime (no chyba że taki projekt nie ma wprowadzanych żadnych zmian od tych 10 lat, to inny temat).
1
@Riddle: trafiłeś jak kulą w płot, właśnie u mojego głównego klienta rozwijam aplikację na laravelu bez ddd która ma obecnie 18 lat :D Początkowo była na czymś innym ale dość wcześnie przeszła na pierwsze wersje laravela :D
1
@ehhhhh: można ale jednak w pewnym momencie warto przejść pewien poziom wyżej.
1
@Riddle: trafiłeś jak kulą w płot, właśnie u mojego głównego klienta rozwijam aplikację na laravelu bez ddd która ma obecnie 18 lat :D Początkowo była na czymś innym ale dość wcześnie przeszła na pierwsze wersje laravela :D
Może się źle wyraziłem, mówiąc "10-letnia aplikacja" miałem na myśli dużą aplikację, która ma dużo feature'ów i wymaga ciągłych i częstych zmian.
Oczywiście że znajdą się aplikacje które mają nawet i 20 lat, ale commitów 20 na rok albo zmian praktycznie żadnych; albo składają się z samych crud'ów bez specjalnej logiki między nimi. Wtedy nie ma znaczenia framework, technologie i użyte metodyki bo takie aplikacje się po prostu bardzo łatwo rozwija. Zgadzam się, że w takich przypadkach faktycznie rozwiązania które długofalowo są gorsze, ale zapewniają szybszy początkowy development mogłyby być lepsze.
Ale jeśli mamy dużą aplikację, która zawiera nietrywialną logikę pomiędzy swoimi elemetami, ma dużo corner'caseów, i nie korzysta z walidacji i case'ów które są przewidziane przez autora takiego frameworka - czyli spora część aplikacji - to wtedy początkowy rozwój takich aplikacji owszem jest szybszy; ale im więcej zmian w takiej aplikacji i im więcej dodatkowych zależności; tym rozwój nad taką aplikacją staje się wykładniczo trudniejszy.
1
@Riddle: No to jest duża aplikacja, cały zespół pracuje tylko nad nią i jest to główny projekt firmy robiący kilku milionowe obroty rocznie :D