Laravel 4 a statické peklo? Kdepak... rubrika: Programování: PHP

1 Michael_Pt
položil/-a 25.10.2013
 
upravil/-a 25.10.2013

Většina z vás pravděpodobně zaregistrovala php framework Laravel, který už je nějaký čas ve verzi 4 a v zahraničí nabírá doslova neuvěřitelnou trakci. Na českém twitteru jsem nicméně zaregistroval spoustu až vysmívajících se názorů typu: "vždyť je to statické peklo" a podobně, které si Laravel vysloužil tak trochu nezaslouženě díky nestandardnímu používání metod. Pro ty co ještě nečetli proto příkládám odkaz na článek, který vysvětluje jak to vlastně je a potvrzuje, že spousta lidí se s názory tak trochu unáhlilo :) http://usman.it/laravel-4-uses-static-not-true/ Podrobněji se tématu věnuje Jeffrey Way ve videu: https://tutsplus.com/lesson/when-they-say-laravel-shouldnt-use-static-me...

Zajímalo by mě zda je tu někdo kdo používá Nette a dostal se i k Laravelu a mohl by oba frameworky nezaujatě alespoň částečně porovnat? V Nette, které mě rovněž zaujalo jsem absolutní začátečník, proto mi nepřísluší porovnávat, přesto si ale troufnu napsat, že z toho co jsem viděl Laravel momentálně nemá konkurenci a povyšuje PHP na úplně nový level.

Komentáře

  • Milan Lempera : které vlastnosti Laravelu podle tebe "povyšují PHP na úplně nový level"? 25.10.2013
odkaz
9 Martin Mystik Jonáš
odpověděl/-a 22.1.2014

Koukal sem na ty články co odkazuješ. Jinak Laravel moc neznám.

To co Laravel používá je klasický Service locator (http://en.wikipedia.org/wiki/Service_locator_pattern) schovaný za statickou fasádu. Service locator je obvykle považovaný za anti-pattern, protože má několik zásadních nevýhod. Za ty hlavní se považuje:

  • skryté závislosti mezi třídami - z rozhraní třídy nepoznáš co všechno používá
  • spoustu chyb detekuješ až v runtime (např. když se dotážeš na službu, kterou v locatoru nemáš)
  • všechno má přístup všude -> svádí k prasení silně provázaného kódu
  • závislost na Service locatoru -> třída nejde použít aniž bys ho měl

Hlavní výhoda je, že se to mnohem jednodušeji používá a pokud máš dostatečně malou aplikaci aby sis v ní udržel přehled tak se může hodit. Jakmile ti ale začne počet tříd a závislostí růst je to o dost složitější.

Z vlastní zkušenosti musím bohužel přiznat, že sem si s použitím Service locator (ne nepodobnému toho z Laravelu) pěkně nabil hubu. V okamžiku, kdy ti aplikace trochu vyroste se z údržby stává peklo.

Service locator totiž porušuje princip, že třídy by svoje závislosti neměla sama někde hledat, ale měla by je dostat.

Za lepší ("správné") řešení se považuje Dependency injection, které používá právě třeba Nette.

Komentáře

  • david.1195 : Mohu se zeptat, jak vypadá podle Vás vypadá "velká webová aplikace postavená na nějakém FW? Obávám se, že to co popisujete, nezažije 90% programátorů, protože většina programuje klasické aplikace typu portál/eshop. ( Tím jsem chtěl jen mírně naznačit, že je naprosto jedno, co používáte - viz např. wordpress :D ) 22.1.2014
  • Martin Mystik Jonáš : Tak řekněme, že za velkou aplikaci považuju něco na čem už musí pracovat více vývojářů a co obsahuje nějakou složitější business logiku, integraci s dalšími systémy, atd.. Tj. myslím že tam spadá už i spousta e-shopů, různé firemní IS, apod. Na malý web s pár stránkami nebo e-shop, který řeší jen poslání objednávky někomu souhlasím že stačí použít v podstatě cokoliv. Jenže když to začne růst je tu problém. 22.1.2014
  • Taco : Portál/EShop je už dost velká aplikace. Hraniční považuji blog -> články, ke článkům komentáře, přihlašování jednoho uživatele, správu obrázků, kategorie a tagy. Na toto bych si ještě ServiceLocator dovedl představit, ale dál už ne. 22.1.2014
  • Stefano : Ja by som service locator uplne nezavrhoval. http://www.slideshare.net/kindblad/dependency-injection-vs-service-locat... 22.1.2014
  • Honza Břešťan : Zrovna tahle prezentace docela zapacha. Autor si plete interface injection s constructor injection interfacu, a service locator pouziva vicemene jenom pro skryvani skutecnych zavislosti. Nebrat. Ale uzitecny vzor to je, jen uplne jindy - treba pro praci s legacy kodem, kdy nejsou zdroje na DI "all the way" a nekde se to zarazi lokatorem. 22.1.2014
  • Taco : A to já bych ho s klidným svědomím zavrhl. 22.1.2014
  • Martin Mystik Jonáš : Žádný vzor nejde používat jako "jediné správné řešení". Každý má svoje výhody a nevýhody. Service locator má i svoje výhody, které v některých případech můžou převážit jeho nevýhody. Ale rozhodně bych ho nepoužíval jako primární řešení. 23.1.2014

Pro zobrazení všech 8 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.