Taustaa
PHP-kehykset: Symfonyn ja Laravelin valitseminen
Tänään, kun aloitat uuden projektin, yksi tärkeimmistä päätöksistä on valita oikea kehys. On vaikea kuvitella monimutkaisen verkkosovelluksen rakentamista tyhjästä nykyään ilman sitä.
Monilla suosituilla verkkokehityskielillä on oletusrakenne, kuten Ruby on Rails for Ruby tai Django Python. PHP: llä ei kuitenkaan ole tällaista yhtä oletusarvoa, ja sillä on useita suosittuja vaihtoehtoja.
Mukaan Google-trendit ja GitHub , suosituimmat PHP-kehykset ovat Symfony, jossa 13,7 tuhatta tähteä ja Laravel 29k tähdellä (tämän artikkelin kirjoittamisen aikaan).
Tässä artikkelissa aion verrata näitä kahta kehystä ja näyttää, kuinka yksinkertaiset, jokapäiväiset ominaisuudet voidaan toteuttaa kullekin. Tällä tavalla voit verrata tosielämän esimerkkien koodia vierekkäin.
Tämä artikkeli edellyttää vahvoja PHP-taitoja ja ymmärrystä MVC: n arkkitehtonisesta paradigmasta, mutta aikaisempaa kokemusta Symfonysta tai Laravelista ei vaadita.
Kilpailijat
Laravel
Puhuessamme Laravelista viittaamme Laravel-versioon 4 ja sen ulkopuolelle. Laravel 4 julkaistiin vuonna 2013 ja edusti kehyksen täydellistä uudelleenkirjoittamista. Kehyksen toimivuus erotettiin erillisistä komponenteista, joita hallittiin Composerilla sen sijaan, että kaikki olisi yhdessä valtavassa koodivarastossa.
Laravel julistaa itsensä kehykseksi nopealle kehitykselle yksinkertaisella ja kauniilla syntaksilla, joka on helppo oppia, lukea ja ylläpitää. Se on vuoden 2016 suosituin kehys Google-trendit , se on kolme kertaa suositumpi kuin muut kehykset, ja edelleen GitHub , sillä on kaksi kertaa enemmän tähtiä kuin kilpailijoilla.
Symfony
Symfony 2 julkaistiin vuonna 2011, mutta sitä ei pidä sekoittaa Symfony 1: een, joka oli täysin erilainen kehys, jolla oli erilaiset periaatteet. Fabien Potencier loi Symfony 2: n, ja nykyinen versio on 3.2, joka on Symfony 2: n inkrementtiversio. Siksi niitä kutsutaan usein yksinkertaisesti Symfony2 / 3: ksi.
Kuten Laravel 4, Symfony 2 on suunniteltu eroteltujen komponenttien joukoksi. Tässä on kaksi hyötyä: Voimme korvata minkä tahansa Symfony-projektin osan ja voimme ottaa minkä tahansa Symfony-komponentin käyttöön ja käyttää sitä muussa kuin Symfony-projektissa. Symfony-komponentit voivat toimia erinomaisina koodiesimerkkeinä, ja niitä käytetään monissa avoimen lähdekoodin projektit kuten Drupal, phpBB ja Codeception. Itse asiassa Laravel itse käyttää vähintään 14 Symfony-komponenttia. Symfony -ympäristön ymmärtäminen tuo siis monia etuja työskennellessäsi muiden projektien kanssa.
Kehysasennukset
Molemmissa kehyksissä on asennusohjelmia ja kääreitä, jotka ovat saatavilla Sisäänrakennettu PHP-verkkopalvelin .
Symfony-asennus
Symfony-asennus on yhtä yksinkertaista kuin seuraava:
# Downloading Symfony installer sudo curl -LsS https://symfony.com/installer -o /usr/local/bin/symfony # Granting permissions to execute installer sudo chmod a+x /usr/local/bin/symfony # Creating new Symfony project symfony new symfony_project # Launching built-in server cd symfony_project/ && php bin/console server:start Se siitä! Symfony-asennuksesi on saatavilla osoitteessa URL http://localhost:8000.
Laravel-asennus
Laravel-asennusprosessi on melkein sama ja yksinkertainen kuin Symfony; Ainoa ero on, että asennat Laravelin asennusohjelman Composerin kautta:
# Downloading Laravel installer using Composer composer global require 'laravel/installer' # Creating new Laravel project laravel new laravel_project # Launching built-in server cd laravel_project/ && php artisan serve Voit nyt käydä http://localhost:8000 ja tarkista Laravel-asennuksesi.
Huomautus: Sekä Laravel että Symfony suorittavat oletusarvoisesti saman paikallisen isännän portin (8000), joten näitä oletusesitteitä ei voi suorittaa samanaikaisesti. Älä unohda pysäyttää Symfony-palvelinta suorittamalla php bin/console server:stop ennen Laravel-palvelimen käynnistämistä.
Tietoja kehyksen asennuksesta
Nämä ovat esimerkkejä perusasennuksesta. Molemmissa kehyksissä on Vagrant-laatikoita edistyneemmille käyttöesimerkkeille, kuten projektien määrittäminen paikallisten toimialueiden kanssa tai useiden projektien suorittaminen kerralla:
Peruskehysmääritykset
Symfony Basic Configuration
Symfony käyttää YAML: ää syntaksina määrityksen määrittelyssä. Oletuskokoonpano sijaitsee app/config/config.yml -kohdassa tiedosto ja näyttää seuraavalta esimerkiltä:
imports: - { resource: parameters.yml } - { resource: security.yml } - { resource: services.yml } framework: secret: '%secret%' router: { resource: '%kernel.root_dir%/config/routing.yml' } # ... # Twig Configuration twig: debug: '%kernel.debug%' strict_variables: '%kernel.debug%' # ... Luo ympäristökohtainen kokoonpano luomalla tiedosto app/config/config_ENV.yml sisältää perusasetukset. Tässä on esimerkki config_dev.yml tiedosto kehitysympäristöä varten:
imports: - { resource: config.yml } # ... web_profiler: toolbar: true # ... Tässä esimerkissä kytketään web_profiler päälle Symfony-työkalu vain kehitysympäristöön. Tämä työkalu auttaa sinua testaamaan ja profiloimaan sovelluksesi suoraan selainikkunassa.
Kokoonpanotiedostoissa voit myös huomata %secret% rakenteet. Niiden avulla voimme laittaa ympäristökohtaiset muuttujat erillisiin parameters.yml tiedosto. Tämä tiedosto voi olla ainutlaatuinen jokaisessa koneessa, eikä sitä ole tallennettu versionhallinnassa. Versiohallintaa varten meillä on erityinen parameters.yml.dist tiedosto, joka on parameters.yml -malli tiedosto.
Tässä on esimerkki parameters.yml tiedosto:
parameters: database_host: 127.0.0.1 database_port: null database_name: symfony database_user: root database_password: null secret: f6b16aea89dc8e4bec811dea7c22d9f0e55593af Laravelin perusmääritykset
Laravel-kokoonpano näyttää hyvin erilaiselta kuin Symfony. Ainoa yhteinen asia, joka heillä on, on, että molemmat käyttävät tiedostoja, joita ei ole tallennettu versionhallintaan (.env Laravel-tapauksessa) ja mallia tämän tiedoston luomiseen (.env.example). Tässä tiedostossa on luettelo avaimista ja arvoista, kuten seuraava esimerkki:
APP_ENV=local APP_KEY=base64:Qm8mIaur5AygPDoOrU+IKecMLWgmcfOjKJItb7Im3Jk= APP_DEBUG=true APP_LOG_LEVEL=debug APP_URL=http://localhost Kuten Symfony YAML-tiedosto, tämäkin Laravelille on luettavissa ihmisille ja näyttää siistiltä. Voit lisäksi luoda .env.testing tiedosto, jota käytetään suoritettaessa PHPUnit-testejä.
Sovelluksen kokoonpano on tallennettu kansioon .php tiedostot config hakemistoon. Peruskokoonpano tallennetaan app.php -kansioon tiedosto- ja komponenttikohtaiset määritykset on tallennettu .php -kansioon tiedostot (esim. cache.php tai mail.php). Tässä on esimerkki config/app.php tiedosto:
'Laravel', 'env' => env('APP_ENV', 'production'), 'debug' => env('APP_DEBUG', false), 'url' => env('APP_URL', 'http://localhost'), 'timezone' => 'UTC', 'locale' => 'en', // ... ]; Kehyksen kokoonpano: Symfony vs. Laravel
Symfonyn sovellusten määritysmekanismien avulla voit luoda erilaisia tiedostoja eri ympäristöihin. Lisäksi se estää sinua lisäämästä monimutkaista PHP-logiikkaa YAML-kokoonpanoon.
Saatat kuitenkin tuntea olosi mukavammaksi Laravelin käyttämän PHP-oletusasetusten syntaksin kanssa, eikä sinun tarvitse oppia YAML-syntaksia.
Reititys ja ohjain
Yleisesti ottaen verkkopohjaisella verkkosovelluksella on yksi ensisijainen vastuu: lukea jokainen pyyntö ja luoda vastaus pyynnön sisällöstä riippuen. Ohjain on luokka, joka vastaa pyynnön muuttamisesta vastaukseksi kutsumalla sovellusmenetelmiä, kun taas reititin on mekanismi, joka auttaa sinua tunnistamaan, mikä ohjainluokka ja menetelmä sinun tulisi suorittaa tietylle pyynnölle.
Luodaan ohjain, joka näyttää /posts/{id}: lta pyydetyn blogiviestisivun reitti.
Reititys ja ohjain Laravelissa
Ohjain
Post::findOrFail($id)]); } } Reititin
Route::get('/posts/{id}', ' [email protected] '); Olemme määrittäneet reitin kohteelle GET pyynnöt. Kaikki pyynnöt, joiden URI vastaa /posts/{id} suorittaa BlogController rekisterinpitäjän show ja välittää parametrin id siihen menetelmään. Ohjaimessa yritämme löytää mallin POST kohteen läpäistyjen id kanssa ja soita Laravelin auttajaan view() renderöimään sivu.
Reititys ja ohjain Symfonyssä
Symfonyssä exampleController on vähän isompi:
getDoctrine()->getRepository('BlogBundle:Post'); $post = $repository->find($id); if ($post === null) { throw $this->createNotFoundException(); } return $this->render('BlogBundle:Post:show.html.twig', ['post'=>$post]); } } Voit nähdä, että olemme jo sisällyttäneet @Route('/posts/{id}”) huomautuksessa, joten meidän on vain sisällytettävä ohjain routing.yml määritystiedosto:
blog: resource: '@BlogBundle/Controller/' type: annotation prefix: / Vaiheittainen logiikka on sama kuin Laravel-tapauksessa.
Reititys ja ohjain: Symfony vs. Laravel
Tässä vaiheessa saatat ajatella, että Laravel on paljon mukavampi kuin Symfony. Tämä on totta alussa. Se näyttää hyvältä ja helpommalta aloittaa. Tosielämän sovelluksissa sinun ei kuitenkaan pitäisi kutsua oppia ohjaimelta. Sen sijaan sinun tulisi soittaa palveluun, joka yrittää löytää viestin tai heittää HTTP 404 -poikkeus .
Mallit
Laravel toimittaa mallimoottorin nimeltä Terä ja Symfony toimittaa Oksa . Molemmissa mallimoottoreissa on kaksi pääominaisuutta:
- Malliperintö
- Lohkot tai osat
Molempien ominaisuuksien avulla voit määrittää perusmallin ohitettavilla osioilla ja alimalleilla, jotka täyttävät kyseisten osioiden arvot.
Tarkastellaan taas esimerkkiä blogiviestisivusta.
Laravel Blade Template -moottori
// base.blade.php @section('page-title') Welcome to blog! @show {% block content %}{% endblock %} // show.html.twig {% extends '@Blog/base.html.twig' %} {% block page_title %}Post {{ post.title }} - read this and more in our blog.{% endblock %} {% block title %}{{ post.title }}{% endblock %} {% block content %} {{ post.content }} {% endblock %} Mallit: Symfony vs. Laravel
Rakenteellisesti Blade- ja Twig-mallit ovat melko samanlaisia. Molemmat luovat mallit PHP-koodiksi ja toimivat nopeasti, ja molemmat toteuttavat ohjausrakenteita, kuten if lauseet ja silmukat. Molempien moottoreiden tärkein ominaisuus on, että ne pakenevat oletusarvoisesti, mikä auttaa estämään XSS-hyökkäyksiä.
Syntaksin lisäksi tärkein ero on, että Blade antaa sinun pistää PHP-koodin suoraan malleihisi ja Twig ei. Sen sijaan Twig antaa sinun käyttää suodattimia.
Esimerkiksi, jos haluat kirjoittaa merkkijonon isoksi, määritä Bladessa seuraava:
{{ ucfirst('welcome friend') }} Toisaalta Twigissä tekisit seuraavaa:
{capitalize } Bladessa on helpompaa laajentaa joitain toimintoja, mutta Twig ei salli suoraa PHP-koodia malleissa.
Riippuvuuden injektio
Sovelluksissa on paljon erilaisia palveluja ja komponentteja, joilla on erilaisia keskinäisiä riippuvuuksia. Sinun on tallennettava kaikki tiedot luotuista esineistä ja niiden riippuvuuksista jollakin tavalla.
Täältä tulee seuraava komponenttimme - Palvelusäiliö . Se on PHP-objekti, joka luo pyydetyt palvelut ja tallentaa tietoja luotuista kohteista ja niiden riippuvuuksista.
Tarkastellaan seuraavaa esimerkkiä: Olet luomassa luokkaa PostService toteuttaa menetelmä, joka on vastuussa uuden blogikirjoituksen luomisesta. Tämä luokka riippuu kahdesta muusta palvelusta: PostRepository, joka on vastuussa tietojen tallentamisesta tietokantaan, ja SubscriberNotifier, joka on vastuussa tilattujen käyttäjien ilmoittamisesta uudesta viestistä. Jotta se toimisi, sinun on läpäistävä nämä kaksi palvelua PostService: n konstruktion argumentteina tai toisin sanoen sinun on pistettävä nämä riippuvuudet.
Esimerkki Symfony-riippuvuuden injektiosta
Määritellään ensin esimerkkipalvelumme:
repository = $repository; $this->notifier = $notifier; } public function create(Post $post) { $this->repository->persist($post); $this->notifier->notifyCreate($post); } } Seuraava on riippuvuuden ruiskutusmääritys:
# src/BlogBundle/Resources/config/services.yml services: # Our main service blog.post_service: class: BlogBundleServicePostService arguments: ['@blog.post_repository', '@blog.subscriber_notifier'] # SubscriberNotifier service. It could also have its own dependencies, for example, mailer class. blog.subscriber_notifier: class: BlogBundleServiceSubscriberNotifier # Repository. Don't dive deep into it's configuration, it is not a subject now blog.post_repository: class: BlogBundleRepositoryPostRepository factory: 'doctrine.orm.default_entity_manager:getRepository' arguments: - BlogBundleEntityPost Nyt voit pyytää postipalvelua missä tahansa Service Container -objektin koodissa. Esimerkiksi ohjaimessa se voi olla jotain tällaista:
// Controller file. $post variable defined below $this->get('blog.post_service')->create($post); Service Container on loistava komponentti, ja se auttaa rakentamaan sovelluksesi seuraavaksi KIINTEÄ suunnitteluperiaatteet.
Liittyvät: Todellisen riippuvuuden injektio Symfony-komponenttien kanssa Esimerkki Laravel-riippuvuuden injektiosta
Laravelissa on paljon helpompaa hallita riippuvuuksia. Tarkastellaan samaa esimerkkiä:
repository = $repository; $this->notifier = $notifier; } public function create(Post $post) { $this->repository->persist($post); $this->notifier->notifyCreate($post); } } Täältä tulee Laravelin kauneus - sinun ei tarvitse luoda riippuvuusmäärityksiä . Laravel etsii riippuvuudet automaattisesti PostService konstruktorin argumenttityypit ja ratkaisee ne automaattisesti.
Voit myös käyttää injektiota ohjaimen menetelmässä käyttääksesi PostService 'vihjaamalla' sitä menetelmä argumenteissa:
'Title', 'content' => 'Content']); $service->create($post); return redirect('/posts/'.$post->id); } } Riippuvuuden injektio: Symfony vs. Laravel
Laravelin automaattinen tunnistus toimii hyvin. Symfonylla on samanlainen ominaisuus nimeltä automaattinen johto ”, Joka on oletusarvoisesti pois päältä ja voidaan kytkeä päälle lisäämällä autowire: true riippuvuusmääritykseen, mutta se vaatii jonkin verran määritystä. Laravel-tapa on yksinkertaisempi.
Objektin relaatiokartoitus (ORM)
Tietokantojen kanssa työskentelemiseksi molemmissa kehyksissä on Object-Relational Mapping (ORM) -ominaisuudet. ORM kartoittaa tietokannan tietueet koodin kohteisiin. Tätä varten sinun on luotava mallit kullekin tietokannan tietuetyypille (tai jokaiselle taulukolle).
Symfony käyttää kolmannen osapuolen projektia Oppi vuorovaikutuksessa tietokannan kanssa, kun taas Laravel käyttää omaa kirjastoa Kaunopuheinen .
Eloquent ORM toteuttaa ActiveRecord-malli työskennellä tietokannan kanssa. Tässä mallissa kukin malli on tietoinen yhteydestä tietokantaan ja voi olla vuorovaikutuksessa sen kanssa. Se voi esimerkiksi tallentaa tietoja tietokantaan, päivittää tai poistaa tietueen.
Oppi toteuttaa Data Mapper -kuvio , jossa mallit eivät tiedä mitään tietokannasta; he ovat tietoisia vain itse tiedoista. Erityinen erillinen kerros EntityManager tallentaa kaikki tiedot mallien ja tietokantojen vuorovaikutuksesta ja hoitaa kaikki toiminnot.
Otetaan esimerkki eron ymmärtämiseksi. Oletetaan, että mallissasi on ensisijainen id avain, otsikko, sisältö ja tekijä. Viestit taulukko tallentaa vain tekijän id, joten sinun on luotava suhde Käyttäjät pöytä.
Oppi
Aloitetaan määrittelemällä mallit:
Tässä loimme mallikartoitustiedot ja voimme nyt käyttää apulaista menetelmän osien luomiseen:
php bin/console doctrine:generate:entities BlogBundle Seuraavaksi määritellään postivaraston menetelmät:
getEntityManager()->persist($post); $this->getEntityManager()->flush(); } /** * Search posts with given author's name * * @param string $name * @return array */ public function findByAuthorName($name) { return $this->createQueryBuilder('posts') ->select('posts') ->join('posts.author', 'author') ->where('author.name = :name') ->setParameter('name', $name) ->getQuery() ->getResult(); } } Nyt voit soittaa näihin menetelmiin palvelusta tai esimerkiksi PostController
// To search for posts $posts = $this->getDoctrine()->getRepository('BlogBundle:Post')->findByAuthorName('Karim'); // To save new post in database $this->getDoctrine()->getRepository('BlogBundle:Post')->persist($post); Kaunopuheinen
Käyttäjä malli toimitetaan Laravelin kanssa ja se on määritetty oletusarvoisesti, joten sinun on määritettävä vain yksi malli mallille Lähettää .
belongsTo('AppUser', 'author_id'); } } Se on kaikki malleille. Eloquentissa sinun ei tarvitse määrittää mallin ominaisuuksia, koska se rakentaa ne dynaamisesti tietokantataulukon rakenteen perusteella. Uuden viestin tallentaminen $post tietokantaan, sinun on soitettava tämä puhelu (esimerkiksi ohjaimelta):
$post->save(); Jos haluat löytää kaikki kirjoittajan tietyn nimen kirjoitukset, paras tapa olisi löytää käyttäjä nimeltä ja pyytää kaikkien käyttäjien viestejä:
$posts = Post::whereHas('author', function ($q) { $q->where('name', 'Karim'); })->get(); ORM: Symfony vs. Laravel
ORM: n suhteen Eloquent näyttää paljon ystävällisemmältä PHP-kehittäjät ja helpompi oppia kuin Oppi.
Event Dispatcher vs. Middleware
Yksi tärkeimmistä puitteiden ymmärrettävistä asioista on sen elinkaari.
Symfony ja Event Dispatcher
Symfony käyttää pyynnön muuntamiseen vastaukseksi EventDispatcheria. Tämän seurauksena potkut erilaisten elinkaaren tapahtumien ja erityisten tapahtumien kuuntelijoiden kanssa näiden tapahtumien käsittelemiseksi. Alussa se lähettää kernel.request tapahtuma, joka sisältää pyyntötietoja. Tämän tapahtuman pääoletuskuuntelija on RouterListener, joka kutsuu reitittimen komponentin etsimään sopivan reittisäännön nykyiselle pyynnölle. Tämän jälkeen muut tapahtumat suoritetaan askel askeleelta. Tyypillisiä tapahtumakuuntelijoita ovat turvallisuustarkistus, CSRF-tunnuksen vahvistus ja kirjausprosessi. Jos haluat lisätä joitain toimintoja pyynnön elinkaareen, sinun on luotava mukautettu EventListener ja tilaa se tarvittavaan tapahtumaan.
Laravel ja Middleware
Laravel käyttää erilaista ratkaisua: väliohjelmistoa. Haluan verrata väliohjelmistoja sipuliin: Sovelluksessasi on tiettyjä kerroksia ja pyyntö kulkee näiden kerrosten läpi matkalla ohjaimeen ja takaisin. Joten jos haluat laajentaa sovelluslogiikkaasi ja lisätä joitakin toimintoja pyynnön elinkaareen, sinun on lisättävä ylimääräinen kerros väliohjelmistoluetteloon, ja Laravel suorittaa sen.
REST-sovellusliittymä
Yritetään luoda perustiedot CRUD-blogikirjoituksen hallinnasta:
- Luo -
POST /posts/ - Lue -
GET /posts/{id} - Päivitä -
PATCH /posts/{id} - Poista -
DELETE /posts/{id}
REST-sovellusliittymä Symfonyssä
Symfonylla ei ole helppoa valmiita ratkaisua nopeaan REST-sovellusliittymän luomiseen, mutta sillä on upeita kolmansien osapuolten paketteja FOSRestBundle ja JMSSerializerBundle.
Tarkastellaan vähiten toimivaa esimerkkiä FOSRestBundle: lla ja JMSSerializerBundle. Kun olet asentanut ne ja ottanut ne käyttöön AppKernel: ssa, voit asettaa nippukokoonpanossa käyttämään JSON-muotoa ja että sitä ei tarvitse sisällyttää URL-pyyntöihin:
#app/config/config.yml fos_rest: routing_loader: default_format: json include_format: false Reititysmäärityksissä sinun on määritettävä, että tämä ohjain toteuttaa REST-resurssin:
#app/config/routing.yml blog: resource: BlogBundleControllerPostController type: rest Olet ottanut käyttöön edellisen esimerkin säilytysmenetelmän arkistossa; nyt sinun on lisättävä poistomenetelmä:
// src/BlogBundle/Repository/PostRepository.php public function delete(Post $post) { $this->getEntityManager()->remove($post); $this->getEntityManager()->flush(); } Seuraavaksi sinun on luotava lomake hyväksyä syöttöpyynnöt ja yhdistää ne malliin. Voit tehdä sen käyttämällä CLI-apuria:
php bin/console doctrine:generate:form BlogBundle:Post Saat luodun lomaketyypin, jolla on seuraava koodi:
add('title')->add('content'); } /** * {@inheritdoc} */ public function configureOptions(OptionsResolver $resolver) { $resolver->setDefaults([ 'data_class' => 'BlogBundleEntityPost', 'csrf_protection' => false ]); } /** * {@inheritdoc} */ public function getBlockPrefix() { return 'post'; } } Toteutetaan nyt ohjain.
Huomautus: koodi, jonka näytän sinulle, ei ole täydellinen. Se rikkoo joitain suunnitteluperiaatteita, mutta se voidaan helposti korjata. Päätarkoitus on näyttää vaihe vaiheelta, miten kukin menetelmä otetaan käyttöön.
getDoctrine()->getRepository('BlogBundle:Post')->find($id); if ($post === null) { $view->setStatusCode(Response::HTTP_NOT_FOUND); } else { $view->setData(['post' => $post]); } return $this->handleView($view); } /** * @param Request $request * @return Response */ public function postPostAction(Request $request) { $view = new View(null, Response::HTTP_BAD_REQUEST); $post = new Post; $form = $this->createForm(PostType::class, $post, ['method' => $request->getMethod()]); $form->handleRequest($request); if ($form->isValid()) { $this->getDoctrine()->getRepository('BlogBundle:Post')->persist($post); $view->setStatusCode(Response::HTTP_CREATED); $postUrl = $this->generateUrl('get_post', ['id' => $post->getId()], UrlGeneratorInterface::ABSOLUTE_URL); $view->setHeader('Location', $postUrl); } else { $view->setData($form->getErrors()); } return $this->handleView($view); } /** * @param $id * @param Request $request * @return Response */ public function patchPostAction($id, Request $request) { $view = new View(null, Response::HTTP_BAD_REQUEST); $post = $this->getDoctrine()->getRepository('BlogBundle:Post')->find($id); if ($post === null) { $view->setStatusCode(Response::HTTP_NOT_FOUND); } else { $form = $this->createForm(PostType::class, $post, ['method' => $request->getMethod()]); $form->handleRequest($request); if ($form->isValid()) { $this->getDoctrine()->getRepository('BlogBundle:Post')->persist($post); $view->setStatusCode(Response::HTTP_NO_CONTENT); $postUrl = $this->generateUrl('get_post', ['id' => $post->getId()], UrlGeneratorInterface::ABSOLUTE_URL); $view->setHeader('Location', $postUrl); } else { $view->setData($form->getErrors()); } } return $this->handleView($view); } /** * @param $id * @return Response */ public function deletePostAction($id) { $view = new View(null, Response::HTTP_NOT_FOUND); $post = $this->getDoctrine()->getRepository('BlogBundle:Post')->find($id); if ($post !== null) { $this->getDoctrine()->getRepository('BlogBundle:Post')->delete($post); $view->setStatusCode(Response::HTTP_NO_CONTENT); } return $this->handleView($view); } } Kun valitset FOSRestBundle, sinun ei tarvitse ilmoittaa reittiä kullekin menetelmälle; noudata vain käytäntöä, jossa on ohjaimen menetelmien nimet, ja JMSSerializerBundle muuntaa mallisi automaattisesti JSONiksi.
REST API Laravelissa
Ensin on määriteltävä reitit. Voit tehdä tämän kohdassa API osan reittisäännöistä sammuttaa jotkin oletusohjelmat ja käynnistää toiset. API -osio sijaitsee routes/api.php tiedosto.
Mallissa tulisi määritellä $fillable ominaisuus välittää muuttujat mallin luonti- ja päivitysmenetelmissä:
Määritetään nyt ohjain:
get('post')); return response(null, Response::HTTP_CREATED, ['Location'=>'/posts/'.$post->id]); } public function update(Post $post, Request $request) { $post->update($request->get('post')); return response(null, Response::HTTP_NO_CONTENT, ['Location'=>'/posts/'.$post->id]); } public function destroy(Post $post) { $post->delete(); return response(null, Response::HTTP_NO_CONTENT); } } Symfony-sovelluksessa käytät FosRestBundle -tunnistetta, joka kääri virheet JSON-tiedostoon. Laravelissa sinun on tehtävä se itse. Sinun on päivitettävä renderöintimenetelmä poikkeuskäsittelijässä palauttaaksesi JSON-virheet odottaessasi JSON-pyyntöjä:
expectsJson()) { $status = 400; if ($this->isHttpException($exception)) { $status = $exception->getStatusCode(); } elseif ($exception instanceof ModelNotFoundException) { $status = 404; } $response = ['message' => $exception->getMessage(), 'code' => $exception->getCode()]; return response()->json($response, $status); } return parent::render($request, $exception); } // ... } REST API: Symfony vs. Laravel
Kuten näette, tyypilliselle REST-sovellusliittymälle Laravel on paljon yksinkertaisempi kuin Symfony.
Voittajan valinta: Symfony vai Laravel?
Laravelin ja Symfonyn välillä ei ole selkeää voittajaa, koska kaikki riippuu lopullisesta tavoitteestasi.
Laravel on parempi valinta, jos:
- Tämä on ensimmäinen kokemuksesi kehyksestä, koska se on helppo oppia, sillä on yksinkertaisempi syntaksin ja parempi oppimateriaali.
- Rakennat käynnistystuotetta ja tarkistat hypoteesi, koska se on hyvä sovellusten nopeaan kehittämiseen ja Laravel-kehittäjät on helppo löytää.
Symfony on paras vaihtoehto, jos:
- Rakennat monimutkaista yrityssovellusta, koska se on hyvin skaalautuva, ylläpidettävä ja hyvin jäsennelty.
- Olet rakentamassa suuren pitkäaikaisen projektin siirtymistä, koska Symfonylla on ennustettavissa olevat julkaisusuunnitelmat seuraavalle kuudelle vuodelle, joten on vähemmän todennäköistä, että yllätyksiä tulee.
