IT rekvalifikace s garancí práce. Seniorní programátoři vydělávají až 160 000 Kč/měsíc a rekvalifikace je prvním krokem. Zjisti, jak na to!
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Diskuze: Laravel a Symfony 2/3

Aktivity
Avatar
Neaktivní uživatel:10.4.2016 22:20

Hoj,

máte někdo zkušenosti s Laravel Frameworkem?
Jíž umím symfony a chtěl bych se pustit do nějakého jiného frameworku.
Docela mě zajímá Laravel, ale nějak nemohu přijít na to, jaký je rozdíl mezi Laravel a Symfony, když Laravel je postaven na Symfony. A proč je vlastně tak populární?

Editováno 10.4.2016 22:22
Odpovědět
10.4.2016 22:20
Neaktivní uživatelský účet
Avatar
Neaktivní uživatel:10.4.2016 22:22

Nejde upravit obrázek ....

Nahoru Odpovědět
10.4.2016 22:22
Neaktivní uživatelský účet
Avatar
David Hartinger
Vlastník
Avatar
Odpovídá na Neaktivní uživatel
David Hartinger:11.4.2016 8:22

Laravel není postavený na Symfony, ale na některých komponentách Symfony. Jsou to v podstatě 2 nezávislé frameworky, i když v něčem si logicky budou podobné. Laravel je vážně poměrně populární, bohužel ačkoli nabízí velmi zajímavé funkce, nepatří mezi nejlépe navržené frameworky, např. nemá Dependency Injection pokud vím, té statiky je tam nějak hodně. Symfony je třeba uzpůsobená pro Doctrine.

Nahoru Odpovědět
11.4.2016 8:22
New kid back on the block with a R.I.P
Avatar
shaman
Člen
Avatar
Odpovídá na Neaktivní uživatel
shaman:11.4.2016 11:28

Ja si nemyslim ze Laravel nema DI alebo ze je tam vela statiky, tiez si myslim ze je dobre navrhnuty framework a dokaze pracovat s Doctrine, takisto ako Symfony dokaze pracovat s PDO alebo Eloquent. Kazdy mame svoj nazor. ;)

Laravel pouziva fakady, aby obalil zlozite kniznice symfony a tak ponukol jednoduche staticke triedy. Tieto staticke triedy su dependantne na injektnutych symfony knizniciach. Cez composer si vies pridat Doctrine. Vsetky fakady Laravelu su detailne popisane na ich stranke.

Priklad:
V kontrolori Laravelu si vyziadam http request (teda GET premenne, url parametre, ...) a vsetko ulozim ho do premennej

$input = Input::all();

Trieda Input je Illuminate\Sup­port\Facades\In­put ktora cez DI zavola Illuminate\Http\Re­quest
Ak si otvoris ten subor, tak najdes ze tato trieda je rozsirena o symfony kniznicu

<?php namespace Illuminate\Http;

use Closure;
use ArrayAccess;
use SplFileInfo;
use RuntimeException;
use Symfony\Component\HttpFoundation\ParameterBag;
use Symfony\Component\HttpFoundation\Request as SymfonyRequest;

class Request extends SymfonyRequest implements ArrayAccess {

Teda laravel len wrapuje symfony kniznice. Kebyze chces mat v premennej $input mat ulozene to iste a pouzival by si symfony, vyzeralo by to asi takto:

use Symfony\Component\HttpFoundation\Request;

$request = Request::createFromGlobals();

// the URI being requested (e.g. /about) minus any query parameters
$request->getPathInfo();

// retrieve GET and POST variables respectively
$request->query->get('foo');
$request->request->get('bar', 'default value if bar does not exist');

// retrieve SERVER variables
$request->server->get('HTTP_HOST');

// retrieves an instance of UploadedFile identified by foo
$request->files->get('foo');

// retrieve a COOKIE value
$request->cookies->get('PHPSESSID');

// retrieve an HTTP request header, with normalized, lowercase keys
$request->headers->get('host');
$request->headers->get('content_type');

$request->getMethod();    // GET, POST, PUT, DELETE, HEAD
$request->getLanguages(); // an array of languages the client accepts

Teda laravel zabali zlozite do jednoducheho. Samozrejme pri tom robi mnoho predpokladov, co je pre programatora najvhodnejsie, ale robi to celkom dobre. Niekomu to vyhovuje, niekomu nie. Dufam ze som vysvetlil trochu rozdiely a preco je Laravel tak popularny.

Nahoru Odpovědět
11.4.2016 11:28
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
David Hartinger
Vlastník
Avatar
Odpovídá na shaman
David Hartinger:11.4.2016 11:45

Ja si nemyslim ze Laravel nema DI alebo ze je tam vela statiky

A vzápětí píšeš:

Laravel pouziva fakady, aby obalil zlozite kniznice symfony a tak ponukol jednoduche staticke triedy. Tieto staticke triedy su dependantne na injektnutych symfony knizniciach.

To je právě ono, je to prostě celé statické, takže je to jednoduché, ale pro velké projekty to IMHO není moc dobrý návrh.

Nahoru Odpovědět
11.4.2016 11:45
New kid back on the block with a R.I.P
Avatar
shaman
Člen
Avatar
Odpovídá na David Hartinger
shaman:11.4.2016 11:54

No a na konci som napisal:

Niekomu to vyhovuje, niekomu nie.

Co clovek to nazor, faktami su cisla popularnosti frameworkov. Teda ci ludia chcu zlozitost, alebo jednoduchost. Cenou jednoduchosti je ze stratits urcite moznosti konfiguracie, ktore tvorcovia laravelu predpokladali za teba.

Keby ludia nechceli jednoduchost, tak tu laravel nie je. Podobne je na tom wordpress. Je to riadne na pi.u CMS ale aj tak ho ludia pouzivaju a je to najpopularnejsie CMS. Odpovedz mi IYHO preco?

Nahoru Odpovědět
11.4.2016 11:54
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
David Hartinger
Vlastník
Avatar
Odpovídá na shaman
David Hartinger:11.4.2016 12:13

Tady se asi neshodneme. Nemyslím si, že best-practices jsou dané tím, co lidem vyhovuje a co ne. Že máš používat DI je prostě fakt a když jí FW nemá, tak je někde něco špatně. Čísla populárnosti frameworku nevypovídá právě vůbec nic, protože ti lidé, kteří ho používají, obvykle profíci nejsou a jednoduše nevědí, jak se to má dělat správě. To je také odpověď na tvou otázku. Spousta lidí v PHP neprogramuje ani objektově.

Nahoru Odpovědět
11.4.2016 12:13
New kid back on the block with a R.I.P
Avatar
mayo505
Tvůrce
Avatar
Odpovídá na David Hartinger
mayo505:11.4.2016 12:40

Najprv chcem povedať, že ma celkom baví ako ľudia nadávajú na Laravel a ani ho nepoznajú (ak niekto povie, že tam nie je DI a všetko je statické tak inak sa to ani nedá povedať). Neviem či je to kvôli Nette, že ho berú ako nejaké "ohrozenie", ale v ČR/SK komunite to vidím veľmi často.

např. nemá Dependency Injection pokud vím

Toto je úplne mimo, Laravel má IoC container a všetko čo pre DI potrebuješ.

To je právě ono, je to prostě celé statické, takže je to jednoduché, ale pro velké projekty to IMHO není moc dobrý návrh.

Toto je tiež sčasti mimo. Áno sú tam fasády, dajú sa použiť ale nemusia. Každá fasáda sa dá nahradiť práve DI. Napísal som aplikáciu čo má asi 20k riadkov kódu a nepoužil som fasádu ani raz. Pod každou fasádou je konkrétna trieda a rozhranie. Napríklad kód Cache::get() sa dá nahradiť DI na interface Illuminate\Cache\Re­pository a konkrétny kód bude $this->cache->get();

nepatří mezi nejlépe navržené frameworky

nemám toľko skúseností s nazeraním do Laravelu pod kapotu, ale tiež si nemyslím, že je to pravda. V tomto sa neviem vyjadriť na 100%, ale ak to staviaš iba na tých dvoch argumentoch tak tie ani nie sú argumenty (fasády sa pod kapotou nepoužívajú). Tak či tak to nijako neovplyvňuje konkrétnu aplikáciu a tá môže byť navrhnutá akokoľvek dobre (ako v hociktorom inom frameworku, jazyku)

Nemyslím si, že best-practices jsou dané tím, co lidem vyhovuje a co ne.

súhlasím. Ale laravel ťa nijako neobmedzuje v používaní tých best practices

Editováno 11.4.2016 12:41
 
Nahoru Odpovědět
11.4.2016 12:40
Avatar
mayo505
Tvůrce
Avatar
mayo505:11.4.2016 12:43

Laravel není postavený na Symfony, ale na některých komponentách Symfony. Jsou to v podstatě 2 nezávislé frameworky, i když v něčem si logicky budou podobné.

S týmto súhlasím

 
Nahoru Odpovědět
11.4.2016 12:43
Avatar
shaman
Člen
Avatar
Odpovídá na David Hartinger
shaman:11.4.2016 13:00

Odkial to vlastne mas ze laravel nepouziva DI. Posuvas ho do urovne nejakeho bananoveho frameworku a to laravel iste nie je. Precitaj si nieco o service provideroch a containeroch napr tu: https://laravel.com/….1/container. Na tej stranke vidis priklad PurchasePodcast a ma konstruktor.

public function __construct(Mailer $mailer)
    {
        $this->mailer = $mailer;
    }

Co si myslis ze je ten mailer? Je to vstrektnuta dependencia. A laravelu je jedno co v nej bude, ci mailgun, ci mandrill alebo klasicke mail z PHP, hlavne ze bude implementovat Illuminate\Con­tracts\Mail\Ma­iler interface. A teraz co myslis odkial je ten $mail injektnuty? Presne zo service provideru a ten mas v config/app.php:

...
        /*
        |--------------------------------------------------------------------------
        | Autoloaded Service Providers
        |--------------------------------------------------------------------------
        |
        | The service providers listed here will be automatically loaded on the
        | request to your application. Feel free to add your own services to
        | this array to grant expanded functionality to your applications.
        |
        */

        'providers' => [

                /*
                 * Laravel Framework Service Providers...
                 */
                'Illuminate\Foundation\Providers\ArtisanServiceProvider',
                'Illuminate\Auth\AuthServiceProvider',
                'Illuminate\Bus\BusServiceProvider',
                'Illuminate\Cache\CacheServiceProvider',
                'Illuminate\Foundation\Providers\ConsoleSupportServiceProvider',
                'Illuminate\Routing\ControllerServiceProvider',
                'Illuminate\Cookie\CookieServiceProvider',
                'Illuminate\Database\DatabaseServiceProvider',
                'Illuminate\Encryption\EncryptionServiceProvider',
                'Illuminate\Filesystem\FilesystemServiceProvider',
                'Illuminate\Foundation\Providers\FoundationServiceProvider',
                'Illuminate\Hashing\HashServiceProvider',
                'Illuminate\Mail\MailServiceProvider',
...

Vsimni si MailServiceProvider injektnuty autormi Laravelu, ale ak chces nieco ine, tak si napises vlastny a tu ho prepises. Zase je to asi prilis jednoduche?

Inak som rad ze namame na vec rovnaky nazor, inak by tato konverzacia bola o tom ako velmi spolu suhlasime. Mimochodom suhlasim s tebou ze kopa ludi neprogramuje objektovo a ze nevedia ako sa to spravne robi.

A mayo505 to pekne vystihol, ze

laravel ťa nijako neobmedzuje v používaní tých best practices

Nahoru Odpovědět
11.4.2016 13:00
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
Neaktivní uživatel:11.4.2016 14:41

Tak se pustím do Laravelu. Určitě se bude hodit :)

PS: Díky všem za odpovědi.

Editováno 11.4.2016 14:42
Nahoru Odpovědět
11.4.2016 14:41
Neaktivní uživatelský účet
Avatar
David Hartinger
Vlastník
Avatar
Odpovídá na mayo505
David Hartinger:11.4.2016 16:44

Jestli má nebo nemá IoC je už pak docela jedno, když ho nemusíš používat :-) Jednou jsem se díval do tutoriálu jak v Laravelu používat db a bylo to celé statické, mam dojem, že to byl oficiální quickstart, sem teď na mobilu, nechce se mi to procházet.

EDIT: Sorry, ale když je tohle v oficiálním tutoriálu, tak je prostě něco špatně - https://laravel.com/…5.1/database

Editováno 11.4.2016 16:50
Nahoru Odpovědět
11.4.2016 16:44
New kid back on the block with a R.I.P
Avatar
mayo505
Tvůrce
Avatar
Odpovídá na David Hartinger
mayo505:11.4.2016 17:51

No podľa tejto logiky je celé PHP zbytočné. Celé zle, načo sú tam objekty keď ich nemusíš používať, to ako keby ani neboli. -_-

Je to tak v dokumentácii preto lebo je to stránka, ktorá nevysvetľuje DI, ale prístup k databáze a takto to jednoduchšie vyznie, lebo nemusí riešiť DI, repozitáre a iné veci, ktoré by sa robili v skutočnej aplikácii. Zameriava sa tým čisto na funkcie na prácu s DB

Možno je chyba, že tvorca dokumentácie predpokladá, že človek čo to číta má nejaké kritické myslenie a vie sa sám rozhodnúť čo je pre jeho aplikáciu dobré.

Editováno 11.4.2016 17:54
 
Nahoru Odpovědět
11.4.2016 17:51
Avatar
Neaktivní uživatel:11.4.2016 19:17

Na Laravelu je špatně hodně věcí, ale je pravda, že se ty věci nemusí používat, což ho ale neomlouvá. Dobře. Mysleme si začátečníka v PHP, říkejme mu třeba Jan. Jan už chvíli v PHP programuje, a od Pavla se dozvěděl, že je tu Laravel - Pro vývojáře jednoduchý framework. Tak si Jan najde dokumentaci Laravelu a začne se učit. Statika sem, statika tam, Janovi to příjde normální, nic si z toho nedělá, protože neví, jak může být statika nebezpečná. Po chvíli si řekne, že si od Laravelu dá odpočinek, a pustí se do své vlasní aplikace. Jeho aplikace je plná statických metod a "god" tříd [1]. "Však to tak má i Laravel," odpovídá na kritiku své aplikace Jan.
Je mi jasné, že třídy v Laravelu můžou používat nějaký DI systém. Ale dámy a pánové, pokud je v oficiální dokumentaci preferována statika a fasády, pak začátečník (nebo i zkušený programátor), může nabýt dojmu, že u Laravelu je to normální. A u začátečníka to může mít fatálnější následky. Jinak se v Laravelu dá psát celkem normální kód. Kromě Eloquentu [1].

[1] https://github.com/…nt/Model.php

Nahoru Odpovědět
11.4.2016 19:17
Neaktivní uživatelský účet
Avatar
mayo505
Tvůrce
Avatar
Odpovídá na Neaktivní uživatel
mayo505:11.4.2016 20:02

Dobre uznávam, že fasády v dokumentácií môžu začiatočníka naviesť na zlú cestu.

Čo sa týka toho, že tam sú - áno statika môže byť zlá. Ale nie každý píše enterprise aplikácie a hľadí dopredu 5 rokov. Ak si chcem urobiť blog cez víkend tak použitie fasád nie je podľa mňa žiaden problém. 99,99% takých víkendových aplikácií nebude potrebovať vymenenie implementácie alebo neviem čo (pri testovaní nemusia robiť problém, dajú sa špeciálne mockovať). Keď robíš tú aplikáciu na tých 5 rokov tak statiku nepoužiješ. Tvorca laravelu sa rozhodol, že vyhovie každému a to, že tam tá statika je neobmedzuje ani nenúti nikoho. Myslím, že je to súčasť demokracie nechať na ľuďoch rozhodnúť sa čo chceš.

K dokumentácií. Ako som vravel, máš pravdu, že môže niekoho zle naučiť. Ale otázka je do akej miery ťa má dokumentácia k frameworku (resp. iba manuál na použitie) učiť programovať. Laravel ti dá veľa možností ako to urobiť (rovnako ako samotné PHP) a sú na to špeciálne weby kde si zistíš čo je lepšie v akom prípade. Dokumentácia všetko vysvetlí napr. tu je zmienené prečo je lepšie použiť DI https://laravel.com/….1/contracts#… a sám sa rozhodneš.

Čo sa týka Eloquentu. Áno je trochu kontroverzný, sám som ho nepoužil, oproti Active Recordu mi príde lepšie použiť Data Mapper. Opäť je tam sloboda, že si môžeš robiť čo chceš. Eloquent je lepší pre tie víkendové aplikácia, Data Mapper pre tie väčšie.

 
Nahoru Odpovědět
11.4.2016 20:02
Avatar
David Hartinger
Vlastník
Avatar
Odpovídá na mayo505
David Hartinger:11.4.2016 21:17

No podľa tejto logiky je celé PHP zbytočné. Celé zle, načo sú tam objekty keď ich nemusíš používať, to ako keby ani neboli. -_-

Ne, to jsi mou logiku nepochopil, jazyk není framework. Kdyby bylo PHP od začátku objektové, tak je někde jinde, ale s tím nikdo nic neudělá. Co chceš na běžné weby používat, JEE? .NET na Windows serveru? To asi ne, že? Zprasené PHP se dá docela dobře napravit tím, že někdo napíše dobrý framework, jako třeba Nette. Pak se v tom dají psát rozumné aplikace. Nevidím žádnou přidanou hodnotu ve frameworku, který je celý statický a dokonce vznikl tím způsobem, že obalil kvalitní framework statickou fasádou.

Nahoru Odpovědět
11.4.2016 21:17
New kid back on the block with a R.I.P
Avatar
Odpovídá na mayo505
Neaktivní uživatel:11.4.2016 21:32

Souhlasím, ale přímo na příkladu fiktivního nováčka Honzy - můžeš mu vtloukat do hlavy, že statika je špatná, ale stejně ji použije jakmile ji uvidí u něčeho většího, co používá víc lidí.

Ohledně toho víkendového blogu existují 3 typy lidí:

  • Člověk, který potřebuje jednorázový blog a (z nějakého důvodu) se ho rozhodne dělat sám. Ten ať si klidně v Laravelu prasí, ale pozor, aby to nebyl typ 2.
  • Člověk, který se na blogu procvičuje a blog je součástí jeho učebního plánu. Tady už je důležité, aby tento člověk vůbec fasády a spol. nepoužíval a programoval podle "best practices".
  • Člověk, který je zkušený programátor. Tento člověk ví, jak to napsat správně. Ten si to může napsat jak chce, ale tipuju, že na 90% si vybere ten "best practices" přístup (pokud ho tedy netlačí deadline, nebo si nechce něco jen rychle zkusit), ale pravda, jsou lidé, kteří jsou zkušení, ví jak by se to "mělo" psát a prasí.

Zastavím se ještě u toho rychle zkusit. Přesně pro toto mi Laravel fasády příjdou jako dělané. Rychle udělat kód, který funguje, ale nepůjde do produkce. Z hlediska udržovatelnosti bych určitě dlouhodobě zvolil jiný přístup.

Toto je můj názor. Upozorňuji, že v PHP jsem dělal dávno, dnes se o něj už jen občas otřu, ale myslím, že toto se dá aplikovat na (skoro) každý jazyk.

Nahoru Odpovědět
11.4.2016 21:32
Neaktivní uživatelský účet
Avatar
mayo505
Tvůrce
Avatar
Odpovídá na Neaktivní uživatel
mayo505:11.4.2016 21:46

Súhlasím zo všetkým čo si napísal. Ale podľa mňa je to z veľkej časti otázka (a chyba) dokumentácie. Je pravda, že tie príklady mohli byť napísané z použitím DI.

Ja som sa hlavne snažil obhájiť to, že Laravel sa dá bez problémov použiť na veľké aplikácie a, že nie je pravda, že tam nie je DI a, že musíš používať fasády. Proste, že vieš spraviť dobre navrhnutú aplikáciu rovnako ako v iných frameworkoch a nič tomu nestojí v ceste.

Editováno 11.4.2016 21:48
 
Nahoru Odpovědět
11.4.2016 21:46
Avatar
Ori I
Člen
Avatar
Odpovídá na David Hartinger
Ori I:11.4.2016 22:46

Dlho som nemal chuť sa na túto tému vyjadrovať ale...

Dávid, zatiaľ si nepovedal žiaden argument na to, že Laravel je zle navrhnutý. Píšeš tu, že je celý statický? kde ? možno tak v dokumentácii. Proste ako tu bolo spomenuté, v našich dvoch republikách sa stretávam len s týmto argumentom a odkazom, že Nette je super.

Prečo? lebo má dokumentáicu po česky ? Alebo preto, že ho v našich milovaných republikách vyžaduje skoro každý zamestnávateľ a to preto lebo ho používajú všetci? (týmto netvrdím, že s nette je niečo zle)

Stále si neukázal, neobhájil svoj argument čo sa týka DI, ale to asi preto, že si si len letmo prebehol dokumentáciu, alebo prečítal nejaký blogpost nejakého Nette lovera(možno k ním aj rovno patríš).

Editováno 11.4.2016 22:46
 
Nahoru Odpovědět
11.4.2016 22:46
Avatar
David Hartinger
Vlastník
Avatar
Odpovídá na Ori I
David Hartinger:11.4.2016 23:49

V Nette jsem nikdy nedělal, mam svůj FW, nejsem ani Nette lover, jedinkrát jsem ho viděl na skoleni, když ho učil Jindra. Nemusíš bys lover ani expert k tomu, abys ty frameworky srovnal dle jejich dokumentace a pokud mas zkušenosti s návrhem softwaru, tak zjistíš, že Nette je kvalitou úplně někde jinde. Dále se k tomu vyjadřovat nebudu, jak jsem psal, lidé pisi i neobjektove, piš si to jak chceš.

Nahoru Odpovědět
11.4.2016 23:49
New kid back on the block with a R.I.P
Avatar
mayo505
Tvůrce
Avatar
Odpovídá na David Hartinger
mayo505:12.4.2016 0:07

Chcel by som vedieť o čo konkrétne, aké sú tie návrhové veci, ktoré má lepšie (Keďže sme si povedali, že Laravel má DI a Fasády sú nepovinné). Teraz sa pýtam ozaj zo zaujímavosti, nemyslím to ironicky alebo čo. Keďže Nette nepoznám tak ho nejdem súdiť, ale zaujíma ma to.

Editováno 12.4.2016 0:08
 
Nahoru Odpovědět
12.4.2016 0:07
Avatar
Pavel Parma
Člen
Avatar
Pavel Parma:13.4.2016 4:07

Jelikož jsem dělal s oběma, tak bych mohl podat menší srovnání.

Laravel se snaží hlavně ulehčit psaní kódu, hlavně těch částí kódu, které se často opakují a mohou být nějakým způsobem generovány na pozadí. Laravel je postaven na symfony. To že využívá třídy symfony také spadá pod vyjádření "postaven na". Co laravel dělá navíc, je zpřehlednění některých částí. Například Routování - Laravel statická definice rout je čistě jejich, ale kompilace routy do regexu je skrze symfony kompiler.

Co ma laravel navrh oproti nette je architektura. A nemluvim o patternu MVC vs MVP, ale tier architecture vs Pipeline. Laravel pouziva Pipileni (jako ma ASP.NET), která umožňuje definování tzv. middlewarů, které se spustí před, nebo až po handlování requestu, což je často opravdu úžasné.

Laravel model je stejně jako v Nette podle patternu Active Row, což je rozdíl oproti symfony, který používá doctrine s patternem Data mapping. Co ale laravel s těmito modely udělal, je naprosto úžasné. V podstatě sdědíte defaultní model, který má již implementované CRUD operace nad databází a další úžasné funkce.

Laravel má nezavrhl ani funkcionální programování, které je na některé věci opravdu lepší, než to psát do objektů (resp. ond definuje public funkci a ta v implementaci volá objekt), takže další bod +; Například php metoda end(), která vrací poslední prvek z pole potřebuje referenci, nemůžete tedy třeba udělat end(implode(....)). Je to prkotina, ale v nette prostě není řešení, byť tak triviální, jako v laravelu, kde udělali prostě trapnou funkci last(), která v implementaci vratí end z argumentu. Vtipné nad jednoduchostí, ale je to tak. Ale je tam i sposuta složitějších fíčur, jako třeba metoda get na Arr objektu, která podporuje dot notation, takze definujete zanoreni srkze string s teckami.

Migrace v laravelu, které jsou navrženy tak, aby dokázali vytvořit schéma do většiny databázových serverů, také nádhera.

Dokumentace. V nette je sice API + nějaké tutoriály, ale uvnitř tříd je naprosto mizerná dokumentace. Na to, že laravel psal jeden člověk (ze začátku), tak je každá třída naprosto zdokumentována, což některým programátorům, jako já, kteří jsou na tohle puntičkáři, přijde jako zásadní. Nemusím hledat něco online, mohu se přesunout do metody a vidím, co dělá a vrací (Type hint pro IDE).

Co mohu v nette vyzdvihnout ja latte, které podporuje makra v tazích. Co je ale naprosto v háji, je podpora pro IDE. nemají plugin, který by fungoval korektně, takže našeptávač html či js v latte souboru je mizérie. Kdežto blade v latte zvolil lepší cestu + si dal záležet na rozšířeních do IDE, takže to funguje vše nádherně. (mám PHPStorm kdyžtak).

No na laravelu bych toho mohl vystihnout i dále, protože toho má mrtě co nabídnout. Co ale mohu také zkritizovat, tak je debugování. Jak jste podotkli, je tam hodně statiky. Na hodně místech sice volá __callStatic, ale pokud je metoda public,tak se volá mimo tuto metodu přímo, takže to může dělat občas bordel. Každopádně, dokud se nic nepokazí, tak je to nádhera, jinak ale happy debugging, už jsem si užil své.

Co ale mohu dodat, tak IoC container je DI container; Není to service locator, ale z jakéhokoli DI můžete udělat service locator, pokud předáte container třídě, takže tohle stranou. Laravel DI je ale chytrý container, který umí jak registrovat objekt na několik způsobů, tak vytvářet neregistrované objekty. To vám zamítne, pokud objekt vyžaduje primitivní datové typy, pokud ale ne, tak se pokusí vytvořit jeho závislosti (a závislostí závislostí...), dokud buď neselže, nebo vše nevytvoří. Podle mě krása, někdo nemá magii rád.

No, udělejte si obrázek sami ;) Já bych laravel doporučil každému, zamiloval jsem se ^^

 
Nahoru Odpovědět
13.4.2016 4:07
Avatar
Odpovídá na Pavel Parma
Dominik Gavrecký:13.4.2016 8:29

Trosku si rýpnem ale chcel si to porovnať a nie vychváliť Laravel :D Preco si napríklad u nette nespomenul Tracy ? Kdyby ? a mnoho ďalšieho :) Tento tvoj nazor je super ale ako objektívne porovnanie to vážme brat nemôžme

Nahoru Odpovědět
13.4.2016 8:29
Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.
Avatar
mayo505
Tvůrce
Avatar
mayo505:13.4.2016 12:21

Je pravda, že keď niekto robí porovnanie tak by mal byť "citovo" nezávislí, ale čo sa týka laravelu tak nepovedal nič čo by nebola pravda.

Myslím si, že je podstatnejšie porovnanie "jadra" frameworku a kdyby tam pokiaľ viem nepatrí, aj pre laravel je milion rôznych balíčkov.

Práve preto som vyzval Dávida (alebo niekoho iného kto pozná Nette lepšie), aby povedal o čo je Nette lepšie lebo tu nepadol žiaden validný argument (ako som vravel statika je nepovinná). A to hlavne z toho návrhového pohľadu lebo veľa funkcií sa dá pridať balíčkami.

 
Nahoru Odpovědět
13.4.2016 12:21
Avatar
shaman
Člen
Avatar
Odpovídá na Dominik Gavrecký
shaman:13.4.2016 12:56

Dominik, mas pravdu ze Pavel nespomenul Tracy, ale takisto nespomenul ani debugbar pre Laravel, ktory je zase len lepsi.
Vsak kukni sam: https://github.com/…vel-debugbar. Tracy alebo debugbar nepovazujem za sucast frameworku. Su to pluginy, ktore si mozes pridat, odobrat alebo nahradit niecim inym.

Podla mna dobry framework ma mat kvalitne a rychle jadro. Toto jadro by nemalo silit Doctrine alebo Tracy. Developer by mal byt schopny jednoducho vymenit hociktory komponent. Ekosystem kniznic musi byt jednoduchy a poskytnut dalsim developerom lahke pridavanie kniznic. Teda jadro by malo byt lightweight a neviazat sa len na urcite kniznice. Vdaka tomu sa okolo frameworku vybuduje skupina developerov, ktory budu vyrabat pluginy pre phpstorm, rozsirenia, kniznice a podobne. Dokumentacia je pre framework dolezita, lebo bez nej je krivka naucenia sa frameworku zase ovela dlhsia.

Ked chcem zabit muchu tak si nezozeniem na nu napalm ale mucholapku. To znamena ze podla velkosti projektu si vyberiem nastroj. Pre blog mi staci Wordpress, pre bezne aplikacie pouzijem laravel lebo som nan zvyknuty a je plno pripravenych kniznic ktore len pripojim a doupravujem. Ked idem budovat velky projekt tak ja prejdem na symfony, ty mozno na nette. To je jedno.

Z mojej osobnej skusenosti si framework vybera sam klient a ja len potvrdim ze na tom idem robit alebo nie. Na ceskom a slovenskom trhu je nette popularny a preto zamestnavatel bude hladat nette developera. Ja zijem v anglicku a nette tu skoro nikto nepozna. To neznamena ale ze je zly. Na tomto trhu musis poznat yii, codeigniter, symfony alebo laravel. Zamestnavatelia tu teda hladaju PHP developra so znalostami MVC a OOP. Cim zlozitejsi framework ovladas tym viac si mozes pytat. Napr wordpress developera zaplatia 20.000librami na rok ale symfony developer si kludne vypyta 55.000libier za rok a to je len nastupny plat.

Na zaver by som len chcel povedat ze je jedno ci je lepsie nette alebo laravel. Je na tebe comu sa budes venovat. Mozes sa zdokonalovat celkovo vo frameworkoch a poznat rozne pristupy v nich alebo sa len koncentrovat na nette. Toto rozhodnutie ovplyvni aj tvoj zarobok v danom regione.

Nahoru Odpovědět
13.4.2016 12:56
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
Odpovídá na shaman
Dominik Gavrecký:13.4.2016 13:45

Aky je rozdiel medzi symphony a Laravel nie su nahodou nejako prepojené ?

Nahoru Odpovědět
13.4.2016 13:45
Hlupák nie je ten kto niečo nevie, hlupákom sa stávaš v momente keď sa na to bojíš opýtať.
Avatar
shaman
Člen
Avatar
Odpovídá na Dominik Gavrecký
shaman:13.4.2016 13:56

Ak si pozries composer.json laravel frameworku tak zistis ze jadro laravel okrem ineho pouziva aj symfony kniznice
https://github.com/…omposer.json

Pokial by si chcel ale uplne ciste jadro laravelu bez vsetkych extra a podobne tak existuje Lumen. Lumen je lightweight jadro Laravelu, vhodne napr na microservices. https://github.com/…omposer.json Tu pouziva len 3 komponenty zo symfony.

Odpoved je teda, ze laravel pouziva nejake komponenty zo symfony.

Nahoru Odpovědět
13.4.2016 13:56
try {...} catch (Exception ignored) { echo " ¯\_(ツ)_/¯ "; }
Avatar
Pavel Parma
Člen
Avatar
Pavel Parma:13.4.2016 23:01

Nepodal jsem zaujaté porovnání, ale neměl jsem úplně tak co porovnávat. Co třeba restfull api. Laravel ho podporuje od začátku, v nette si to musíte udělat sami.

Buď mohu porovnat průchod handlování (s tím spojenou rychlost, náročnost atp.), nebo co mi frameworku umožňuje a s čím pomáhá. Problém je, že laravel toho umí tolik, co nette prostě ne, že by porovnání bylo typu

Laravel: xy | Nette: nepodporuje

 
Nahoru Odpovědět
13.4.2016 23:01
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 28 zpráv z 28.