[8locx]

Halo, #programowanie, #php. Korzysta ktoś z #laravel i miał kiedyś styczność z codeigniterem? Warto przeskakiwać, jakie są plusy laravela?

[K.....a]

@8locx: na symphony sie przeskocz

[Vinniczek]

@8locx:
Jak tylko możesz to przechodź (czy na larwę to już inna sprawa, pewnie zaraz pojawi się ktoś w stylu TYLKO SYMFONY HURR DURR xd), CI to przestarzały framework.

[8locx]

Jasne, że mogę, nie mam zamiaru stać w miejscu, już trochę przy tym siedzę, tym bardziej, że CI stoi w miejscu cały czas, nie licząc drobnych zmian gównowartych, @Vinniczek a co z larwą nie tak? @Klopsztanga najlepsze wyjście to symphony ogólnie? :)

[K.....a]

@8locx: symphony to projekt, do którego można "fapować" pod wzgledem jakosci kodu jak i tez struktury, DI itp. Po prostu to jest taka truskawka. Ale niestety, z powodu ze programisci nie chcieli sie uczyc MVC, woleli nadal miec brzydki kod i nazywac sie programistami, powstal Laravel, co zaimplementowal Fasady, ktore sa gowniane, jak i tez nie ma jednolitego kierunku pisania.

[Vinniczek]

@8locx:
Ma parę niestandardowych rozwiązań architektonicznych i ze względu na to jak jest prowadzona nie jest bardzo enterprise friendly. Poczytaj, jest sporo argumentów w internecie. Ale moim zdaniem jak robisz dla siebie to nie bardzo ma znaczenie, który nowoczensy framework wybierzesz. (Co innego jak będziesz szukał jakieś pracy ;)

@Klopsztanga:
Bo widzę, że któryś raz - Symfony, nie Symphony ;)

[MacDada]

symphony

@Klopsztanga: Symfony*

[MacDada]

Warto przeskakiwać?

@8locx: Z CI jak najbardziej.

[MacDada]

Warto przeskakiwać [na Laravela]?

@8locx: Zdecydowanie nie.

[MacDada]

jakie są plusy laravela?

@8locx: Będą Ci pisali, że prostota, że szybko się robi, etc => ale są to złudne zapowiedzi. Jak robisz coś więcej niż stronkę wizytówkę dla janusza za 200 zł, to trzymaj się z daleka.

[MacDada]

pewnie zaraz pojawi się ktoś w stylu TYLKO SYMFONY HURR DURR xd

@Vinniczek: Witam serdecznie!

[MacDada]

co z larwą nie tak?

@8locx: Użyj trochę Google i wróć, nie ma sensu, żeby się rozpisywać na temat, który jest opisany w gazylionie miejsc w sieci.

W skrócie: #!$%@? kod frameworka i #!$%@? kod używających frameworka.

[MacDada]

Laravel, co zaimplementowal Fasady

@Klopsztanga: Ekhem. Laravel implementuje statyczne proxy. Generalnie jakiś gówno–misz–masz. Ciężko powiedzieć. Ale nie są to fasady. To, że pewien ignorant zdecydował się ten swój wymysł tak nazywać, nie znaczy, że teraz wszyscy wokół mają nagle stosować jego #!$%@?ą terminologię.

[MQs]

@MacDada: Z rok,pół roku temu widziałem na SO pytanie jak w tym używać dependency injection zamiast statyków. Odpowiedzi niezbyt konkretne - nawet bonus nie pomógł:)

[K.....a]

@MacDada: no to programiści laravela od samego początku są #!$%@? xD

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

[K.....a]

@MQs: przecież ten ich twór komplikuje DI, to jest mocno #!$%@?. Serwisy muszą być wstrzykiwane i tyle. A to co #!$%@? to tylko po to, by gównoprogramiści nie musieli się uczyć, przez co mamy #!$%@? github gównianym kodem xD

[MacDada]

Z rok,pół roku temu widziałem na SO pytanie jak w tym używać dependency injection zamiast statyków. Odpowiedzi niezbyt konkretne - nawet bonus nie pomógł:)

@MQs: Z tego co wiem to da się normalnie robić DI. Tylko czemu jakiś artisan miałby to robić, skoro guru mówi, że niepotrzbne?

[K.....a]

@MacDada: ot co xD PHP przebiegł długą drogę do normalności, od zjeb-coding do pięknego Symfony 3, gdzie standardy są utrzymywane, i w ogóle miód i cukiereczki, fapanie do PSR

Ale #!$%@? nie. Znajdzie się jakiś fork symfony, że ktoś pomyśli: eee #!$%@?, te całe DI jest za trudne, chce pisać #!$%@? ale szybko, tak aby rozwój oprogramowania był #!$%@? - a moduły zamknięte. I tak powstał Laravel.

[MacDada]

przecież ten ich twór komplikuje DI, to jest mocno #!$%@?

@Klopsztanga: Generalnie DI to nadal jest, w jakimś stopniu. Bo faktycznie konkretna implementacja jest przekierowywana i tym samym następuję odwrócenie zależności. ALE:

1. pozostaje zahardkodowane odwołanie do implementacji frameworka (do proxy) – nieodwrócone
2. zależności pozostają ukryte – musisz przeanalizować klasę, żeby wiedzieć co wymaga do działania – zamiast zajrzeć po prostu w konstruktor

Więc ogólnie: fakt, #!$%@? ;)

[8locx]

Super! Dzięki wielkie! Wszystko przyjąłem do siebie i będę pracował :) Miłego wieczoru.

[K.....a]

@MacDada: DI służy tylko do podmiany ewentualnych providerów do fasad. Ale jak ktoś w serwisie zamiast wstrzykiwać serwisu przez DI, tylko korzysta z tych jeb%#@% fasad, nie masz możliwości ustawienia np. customowego providera do tego serwisu. Bo ktoś po prostu używa Cache::get("gowno") zamiast $this->cache->get("gowno"), gdzie zmienna klasy cache jest wstrzyknięta podczas inicjalizacji klasy serwisu.

Tak więc. Do nienawiści do Laravela, tak zostałem wychowany! CHWDL. Tylko dobry kod może być na serwerze!