@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: 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.
@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 ;)
@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: 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ł:)
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?
przecież ten ich twór komplikuje DI, to jest mocno z-----e
@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
@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
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.
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 ;)
@Klopsztanga: Symfony*
@8locx: Z CI jak najbardziej.
@8locx: Zdecydowanie nie.
@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.
@Vinniczek: Witam serdecznie!
https://laravel.com/docs/5.3/facades
@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?
@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
Tak więc. Do nienawiści do Laravela, tak zostałem wychowany! CHWDL. Tylko dobry kod może być na