Tagumine Ots

PHP raamistikud: Symfony ja Laraveli vahel valimine

Täna on uue projekti alustamisel üks peamisi otsuseid õige raamistiku valimine. Tänapäeval on keeruline ette kujutada keeruka veebirakenduse loomist nullist ilma selleta.

Paljudel veebiarenduse populaarsetel keeltel on oma „vaikimisi” raamistik, näiteks Ruby on Rails for Ruby või Django Python. Kuid PHP-l pole sellist ühtset vaikeväärtust ja sellel on mitu populaarset valikut.

Vastavalt Google'i trendid ja GitHub , kõige populaarsemad PHP raamistikud on Symfony 13,7 tuhande tähega ja Laravel 29k tähega (selle artikli kirjutamise ajal).

Selles artiklis võrdlen neid kahte raamistikku ja näitan teile, kuidas rakendada lihtsaid igapäevaseid funktsioone. Nii saate kõrvuti võrrelda tõsieluliste näidete koodi.

See artikkel eeldab tugevat PHP-oskust ja MVC arhitektuuriparadigma mõistmist, kuid varasemat kogemust Symfony või Laraveli kohta pole vaja.

Võistlejad

Laravel

Laravelist rääkides peame silmas Laraveli versiooni 4 ja kaugemaid. Laravel 4 ilmus 2013. aastal ja esindas raamistiku täielikku ümberkirjutamist. Raamistiku funktsionaalsus lahutati eraldi komponentideks, mida hallati koos Composeriga, selle asemel, et kõik oleks ühes tohutus koodihoidlas.

Laravel kuulutab ennast kiire arengu raamistikuks, millel on lihtne ja ilus süntaks, mida on lihtne õppida, lugeda ja hooldada. See on 2016. aasta populaarseim raamistik Google'i trendid , see on kolm korda populaarsem kui muud raamistikud ja edasi GitHub , sellel on kaks korda rohkem tähti kui konkurentidel.

Symfony

Symfony 2 ilmus 2011. aastal, kuid seda ei tohi segi ajada Symfony 1-ga, mis oli täiesti erinev raamistik, millel olid erinevad aluspõhimõtted. Fabien Potencier lõi Symfony 2 ja praegune versioon on 3.2, mis on Symfony 2 kasvav versioon. Seetõttu nimetatakse neid sageli lihtsalt Symfony2 / 3-ks.

Nagu ka Laravel 4, on ka Symfony 2 loodud lahutatud komponentide komplektina. Siin on kaks eelist: me võime asendada Symfony projekti mis tahes komponendi ning võime võtta ja kasutada mis tahes Symfony komponente mitte-Symfony projektis. Symfony komponendid võivad olla suurepärased koodinäited ja neid kasutatakse paljudes avatud lähtekoodiga projektid nagu Drupal, phpBB ja Codeception. Tegelikult kasutab Laravel ise mitte vähem kui 14 Symfony komponenti. Symfony mõistmine annab teile teiste projektidega töötamisel palju eeliseid.

Raamistiku installid

Mõlemal raamistikul on installijad ja ümbrised, mis on saadaval PHP sisseehitatud veebiserver .

Symfony installimine

Symfony installimine on sama lihtne kui järgmine:

# 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

See on kõik! Teie Symfony install on saadaval aadressil URL http://localhost:8000.

Laraveli paigaldamine

Laraveli installiprotsess on peaaegu sama ja sama lihtne kui Symfony puhul; ainus erinevus on see, et installite Laraveli installeri Composeri kaudu:

# 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

Nüüd saate külastada http://localhost:8000 ja kontrollige oma Laraveli installimist.

Märge: Nii Laravel kui ka Symfony töötavad vaikimisi sama kohaliku hosti pordiga (8000), nii et neid vaikeprojekte ei saa samaaegselt käivitada. Ärge unustage Symfony serveri peatamist käivitades php bin/console server:stop enne Laraveli serveri käivitamist.

Teave raamistiku installimise kohta

Need on näited põhiinstallatsioonist. Täpsemate kasutusnäidete jaoks, näiteks kohalike domeenidega projektide konfigureerimise või mitme projekti korraga käivitamise kohta, pakuvad mõlemad raamistikud Vagranti kaste:

Laraveli kodutalu ,
Symfony kodutalu .

Raamistiku põhikonfiguratsioonid

Symfony põhikonfiguratsioon

Symfony kasutab oma konfiguratsiooni täpsustamisel süntaksina YAML-i. Vaikekonfiguratsioon asub app/config/config.yml fail ja näeb välja järgmine näide:

Pankroti peatükis 11 võib saneerimiskavasid teha ainult võlgnik.

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%' # ...

Keskkonnaspetsiifilise konfiguratsiooni loomiseks looge fail app/config/config_ENV.yml sisaldab põhilisi konfiguratsiooniparameetreid. Siin on näide config_dev.yml arenduskeskkonna fail:

imports: - { resource: config.yml } # ... web_profiler: toolbar: true # ...

See näide lülitab sisse web_profiler Symfony tööriist ainult arenduskeskkonnale. See tööriist aitab teil oma rakendust siluda ja profiili sirvida otse brauseriaknas.

Konfiguratsioonifailides võite märgata ka %secret% konstruktsioonid. Need võimaldavad meil panna keskkonnaspetsiifilised muutujad eraldi parameters.yml faili. See fail võib olla igas masinas ainulaadne ja seda ei salvestata versioonikontrolli all. Versioonihalduseks on meil spetsiaalne parameters.yml.dist fail, mis on parameters.yml malli faili.

Siin on näide parameters.yml fail:

parameters: database_host: 127.0.0.1 database_port: null database_name: symfony database_user: root database_password: null secret: f6b16aea89dc8e4bec811dea7c22d9f0e55593af

Laraveli põhikonfiguratsioon

Laraveli konfiguratsioon näeb Symfony omast väga erinev välja. Ainus ühine omadus on see, et nad mõlemad kasutavad faile, mida pole salvestatud versioonikontrolli all (.env Laraveli puhul) ja malli selle faili genereerimiseks (.env.example). Sellel failil on võtmete ja väärtuste loend, näiteks järgmine näide:

APP_ENV=local APP_KEY=base64:Qm8mIaur5AygPDoOrU+IKecMLWgmcfOjKJItb7Im3Jk= APP_DEBUG=true APP_LOG_LEVEL=debug APP_URL=http://localhost

Nagu Symfony YAML-fail, on ka see Laraveli jaoks inimloetav ja näeb välja puhas. Lisaks saate luua .env.testing fail, mida kasutatakse PHPUniti testide käivitamisel.

Rakenduse konfiguratsioon on salvestatud .php failid config kataloogi. Põhikonfiguratsioon on salvestatud kausta app.php faili- ja komponendispetsiifiline konfiguratsioon on salvestatud .php failid (nt cache.php või mail.php). Siin on näide config/app.php fail:

 'Laravel', 'env' => env('APP_ENV', 'production'), 'debug' => env('APP_DEBUG', false), 'url' => env('APP_URL', 'http://localhost'), 'timezone' => 'UTC', 'locale' => 'en', // ... ];

Raamistiku seadistamine: Symfony vs Laravel

Symfony rakenduse konfiguratsioonimehhanismid võimaldavad teil luua erinevaid keskkondade jaoks erinevaid faile. Lisaks ei lase see teil keerukat PHP-loogikat YAML-i konfiguratsioonis sisestada.

Laraveli kasutatav PHP vaikeseadistuste süntaks võib teile siiski mugavam olla ja te ei pea õppima YAML-i süntaksit.

Marsruutimine ja kontroller

Üldiselt on taustveebirakendusel üks peamine kohustus: lugeda iga taotlust ja luua vastus, sõltuvalt päringu sisust. Kontroller on klass, mis vastutab päringu vastuse muutmise eest, kutsudes rakenduse meetodeid, samas kui ruuter on mehhanism, mis aitab teil tuvastada, millist kontrolleri klassi ja meetodit peaksite konkreetse päringu jaoks täitma.

c++ keeles kirjutatud programmid

Loome kontrolleri, mis kuvab /posts/{id} -lt nõutud ajaveebi postituse lehe tee.

Marsruutimine ja kontroller Laravelis

Kontroller

Post::findOrFail($id)]); } }

Ruuter

Route::get('/posts/{id}', ' [email protected] ');

Oleme määranud marsruudi GET jaoks taotlusi. Kõik päringud, mille URI vastab /posts/{id} käivitab BlogController kontrolleri show meetod ja edastab parameetri id selle meetodi juurde. Kontrollerist püüame leida mudeli POST objekti möödunud id ja helistage Laraveli abistajale view() lehe renderdamiseks.

Marsruutimine ja kontroller Symfony'is

Symfony'is exampleController on natuke suurem:

getDoctrine()->getRepository('BlogBundle:Post'); $post = $repository->find($id); if ($post === null) { throw $this->createNotFoundException(); } return $this->render('BlogBundle:Post:show.html.twig', ['post'=>$post]); } }

Näete, et oleme juba lisanud @Route('/posts/{id}”) märkuses, nii et peame lihtsalt kontrolleri kaasama routing.yml konfiguratsioonifail:

blog: resource: '@BlogBundle/Controller/' type: annotation prefix: /

Samm-sammuline loogika on sama mis Laraveli juhtumi puhul.

Marsruutimine ja kontroller: Symfony vs Laravel

Selles etapis võite arvata, et Laravel on palju toredam kui Symfony. See on alguses tõsi. See näeb välja nii parem kui ka lihtsam. Reaalsetes rakendustes ei tohiks aga õpetajat doktriinile helistada. Selle asemel peaksite helistama teenusesse, kes üritab postitust leida või visata HTTP 404 erand .

Mallid

Laraveli laevad malli mootoriga Tera ja Symfony laevad koos Oks . Mõlemal mallimootoril on kaks peamist omadust:

Malli pärimine
Plokid või sektsioonid

Mõlemad funktsioonid võimaldavad teil määratleda põhimalli koos alistatavate jaotistega ja alamallidega, mis täidavad nende jaotiste väärtusi.

Vaatame uuesti blogipostituse lehe näidet.

Laraveli labamalli mootor

// 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 %}

Mallid: Symfony vs Laravel

Struktuurselt on Blade ja Twig mallid üsna sarnased. Mõlemad genereerivad mallid PHP-koodiks ja töötavad kiiresti ning mõlemad rakendavad juhtimisstruktuure, näiteks if avaldused ja tsüklid. Mõlemal mootoril on kõige olulisem omadus see, et nad pääsevad väljundist vaikimisi, mis aitab ära hoida XSS-rünnakuid.

Süntaksi kõrval on peamine erinevus see, et Blade võimaldab teil PHP-koodi otse mallidesse sisestada ja Twig mitte. Selle asemel lubab Twig kasutada filtreid.

Näiteks kui soovite stringi suurtähtedega kirjutada, määrake Blade'is järgmised:

{{ ucfirst('welcome friend') }}

Seevastu Twigis teete järgmist:

{capitalize }

Blade'is on mõningate funktsioonide laiendamine lihtsam, kuid Twig ei luba mallides otsest PHP-koodi.

Sõltuvuse süstimine

Rakendustel on palju erinevaid teenuseid ja komponente, millel on erinev vastastikune sõltuvus. Peate kuidagi salvestama kogu teabe loodud objektide ja nende sõltuvuste kohta.

Siit tuleb meie järgmine komponent - Teeninduskonteiner . See on PHP-objekt, mis loob nõutavad teenused ja salvestab teavet loodud objektide ja nende sõltuvuste kohta.

Vaatleme järgmist näidet: loote klassi PostService uue blogipostituse loomise eest vastutava meetodi juurutamiseks. See klass sõltub kahest muust teenusest: PostRepository, mis vastutab teabe salvestamise eest andmebaasi, ja SubscriberNotifier, mis vastutab tellitud kasutajate teavitamise eest uue postituse eest. Selle toimimiseks peate need kaks teenust edastama PostService konstruktori argumentidena või teisisõnu peate neid sõltuvusi süstima.

Symfony sõltuvuse süstimise näide

Kõigepealt määratleme oma näidisteenused:

  repository = $repository; $this->notifier = $notifier; } public function create(Post $post) { $this->repository->persist($post); $this->notifier->notifyCreate($post); } } Järgmine on sõltuvuse süstimise konfiguratsioon:
# 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 Nüüd saate oma teenust taotleda teenusekonteineri objekti mis tahes koodis. Näiteks kontrolleris võib see olla umbes selline:
// Controller file. $post variable defined below $this->get('blog.post_service')->create($post); Teeninduskonteiner on suurepärane komponent ja see aitab teie rakendust järgida TAHKE kujunduspõhimõtted.
  Seotud:  Tõelise sõltuvuse süstimine Symfony komponentidega  Laraveli sõltuvuse süstimise näide
 Laravelis on palju lihtsam sõltuvusi hallata. Vaatleme sama näidet:
  repository = $repository; $this->notifier = $notifier; } public function create(Post $post) { $this->repository->persist($post); $this->notifier->notifyCreate($post); } } Siit tuleb Laraveli ilu - pole vaja luua sõltuvuskonfiguratsioone . Laravel otsib sõltuvusi automaatselt PostService oma konstruktori argumentides tüübid ja lahendab need automaatselt.
 Süstimist saab kasutada ka kontrolleri meetodil PostService kasutamiseks meetodi argumentides seda 'tüübile vihjates':
 'Title', 'content' => 'Content']); $service->create($post); return redirect('/posts/'.$post->id); } } Sõltuvuse süstimine: Symfony vs Laravel
 Laraveli automaatne tuvastamine töötab suurepäraselt. Symfony'l on sarnane võime, mida nimetatakse automaatne traat ”, Mis on vaikimisi välja lülitatud ja mille saab sisse lülitada, lisades autowire: true teie sõltuvuse konfiguratsioonile, kuid see nõuab teatud konfiguratsiooni. Laraveli viis on lihtsam.
 Objektide suhteline kaardistamine (ORM)
 Andmebaasidega töötamiseks on mõlemal raamistikul objektide-relatsioonide kaardistamise (ORM) funktsioonid. ORM kaardistab andmebaasi kirjed koodi objektidesse. Selleks peate looma mudelid oma andmebaasis igale kirjetüübile (või igale tabelile).
 Symfony kasutab kolmanda osapoole projekti Õpetus andmebaasiga suhtlemiseks, samal ajal kui Laravel kasutab oma raamatukogu Kõnekas .
 Kõnekas ORM rakendab ActiveRecordi muster andmebaasiga töötamiseks. Selles mustris on iga mudel teadlik ühendusest andmebaasiga ja saab sellega suhelda. Näiteks võib see andmeid andmebaasi salvestada, kirjet värskendada või kustutada.
 Õpetus viib ellu Data Mapperi muster , kus mudelid ei tea andmebaasist midagi; nad on teadlikud ainult andmetest endast. Spetsiaalne eraldi kiht EntityManager salvestab kogu teabe mudelite ja andmebaaside koostoime kohta ning haldab kõiki toiminguid.
 Võtame erinevuse mõistmiseks näite. Oletame, et teie mudelil on peamine id võti, pealkiri, sisu ja autor. The Postitused tabelis on salvestatud ainult autor id, seega peate looma seose Kasutajad tabel.
kui nõudluse hinnaelastsus mõõdab 2, tähendab see, et tarbijad seda teeksid
 Õpetus
 Alustame mudelite määratlemisega:
 Siin lõime mudeli kaardistamise teabe ja saame nüüd kasutada abimeest meetodi tüvede loomiseks:
php bin/console doctrine:generate:entities BlogBundle Järgmisena määratleme postituste hoidla meetodid:
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(); } } Nüüd saate neid meetodeid teenusest helistada või näiteks 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); Kõnekas
 The Kasutaja mudel tarnitakse koos Laraveliga ja see on vaikimisi määratletud, seega peate selle jaoks määratlema ainult ühe mudeli Postitus .
belongsTo('AppUser', 'author_id'); } } See on kõik mudelite jaoks. Rakenduses Eloquent ei pea te mudeli atribuute määratlema, kuna see ehitab need andmebaasi tabeli struktuuri põhjal dünaamiliselt. Uue postituse salvestamiseks $post andmebaasi, peate selle kõne tegema (näiteks kontrollerilt):
$post->save(); Kõigi eesnimega autori kõigi postituste leidmiseks oleks parim viis leida oma nimega kasutaja ja taotleda kõigi kasutajate postitusi:
$posts = Post::whereHas('author', function ($q) { $q->where('name', 'Karim'); })->get(); ORM: Symfony vs Laravel
 ORMi osas näeb Eloquent palju sõbralikum välja PHP arendajad ja lihtsam õppida kui Õpetus.
 Ürituste dispetšer vs vahevara
  
 Üks olulisemaid asju, mida raamistiku mõistmisel mõista, on selle elutsükkel.
 Symfony ja sündmuste dispetšer
 Taotluse vastuseks teisendamiseks kasutab Symfony EventDispatcherit. Järelikult vallandab see erinevad olelusringi sündmused ja erisündmuste kuulajad nende sündmuste käsitlemiseks. Alguses saadab see kernel.request sündmus, mis sisaldab päringu teavet. Selle sündmuse peamine vaikekuulaja on RouterListener, mis kutsub ruuteri komponendi üles, et leida praegusele päringule sobiv marsruudireegel. Pärast seda käivitatakse samm-sammult teised sündmused. Tüüpilised sündmuste kuulajad on turvakontroll, CSRF-i loa kontrollimine ja logimisprotsess. Kui soovite päringu elutsüklisse lisada funktsionaalsust, peate looma kohandatud EventListener ja tellige see vajalikule sündmusele.
 Laravel ja vahevara
 Laravel kasutab teistsugust lahendust: vahevara. Mulle meeldib võrrelda vahevara sibulaga: teie rakendusel on teatud kihid ja päring läbib need kihid teel kontrollerisse ja tagasi. Niisiis, kui soovite laiendada oma rakenduse loogikat ja lisada päringu elutsüklisse mõned funktsioonid, peate lisama oma vahevara loendisse täiendava kihi ja Laravel täidab selle.
 REST API
 Proovime blogipostituse haldamiseks luua CRUD-i põhinäite:
  Loo - POST /posts/
 Loe - GET /posts/{id}
 Uuenda - PATCH /posts/{id}
 Kustuta - DELETE /posts/{id}
 
 REST API Symfony'is
 Symfonyl pole REST API kiireks loomiseks lihtsat paketti kuuluvat lahendust, kuid sellel on suurepäraseid kolmanda osapoole pakette FOSRestBundle ja JMSSerializerBundle.
 Vaatleme FOSRestBundle -ga minimaalset töötavat näidet ja JMSSerializerBundle. Kui olete need installinud ja rakenduses AppKernel sisse lülitanud, saate kimpude konfiguratsioonis seadistada, et kasutate JSON-vormingut ja seda ei pea URL-i päringutesse lisama:
#app/config/config.yml fos_rest: routing_loader: default_format: json include_format: false Marsruutimise konfiguratsioonis peate määrama, et see kontroller rakendab REST-ressurssi:
#app/config/routing.yml blog: resource: BlogBundleControllerPostController type: rest Te juurutasite eelmises näites hoidlas püsimeetodi; nüüd peate lisama kustutusmeetodi:
// src/BlogBundle/Repository/PostRepository.php public function delete(Post $post) { $this->getEntityManager()->remove($post); $this->getEntityManager()->flush(); } Järgmisena peate looma a vormiklass sisenditaotluste vastuvõtmiseks ja nende mudeli järgi kaardistamiseks. Saate seda teha CLI-abistaja abil:
php bin/console doctrine:generate:form BlogBundle:Post Teile saadetakse järgmise koodiga loodud vormitüüp:
add('title')->add('content'); } /** * {@inheritdoc} */ public function configureOptions(OptionsResolver $resolver) { $resolver->setDefaults([ 'data_class' => 'BlogBundleEntityPost', 'csrf_protection' => false ]); } /** * {@inheritdoc} */ public function getBlockPrefix() { return 'post'; } } Rakendame nüüd oma kontrollerit.
  Märge: kood, mida ma teile näitan, pole täiuslik. See rikub mõningaid disainiprintsiipe, kuid seda saab hõlpsasti ümber kujundada. Peamine eesmärk on näidata teile, kuidas iga meetodit järk-järgult rakendada.
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); } } Funktsiooniga FOSRestBundle ei pea te iga meetodi jaoks marsruuti deklareerima; lihtsalt järgige kontrolleri meetodi nimedega kokkuleppeid ja JMSSerializerBundle teisendab teie mudelid automaatselt JSON-iks.
 REST API Laravelis
 Esiteks peate määratlema marsruudid. Seda saate teha jaotises API osa marsruudi reeglitest, et lülitada välja mõned vaikevaraosakomponendid ja lülitada sisse teised. API jaotis asub routes/api.php faili.
Mudelis peaksite määratlema $fillable atribuut mudeli loomis- ja värskendamismeetodites muutujate edastamiseks:
Nüüd määratleme kontrolleri:
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'is kasutate FosRestBundle, mis mässis JSON-i vead. Laravelis peate seda ise tegema. Peate värskendama renderdamismeetodit eranditöötluses, et tagastada JSON-i tõrkeid JSON-i taotluste ootel:
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
 Nagu näete, on tüüpilise REST API jaoks Laravel palju lihtsam kui Symfony.
 Võitja valimine: Symfony või Laravel?
 Laraveli ja Symfony vahel pole kindlat võitjat, kuna kõik sõltub teie lõppeesmärgist.
  Laravel on parem valik, kui: 
mis on node.js serveripoolne javascript
  See on teie esimene kogemus raamistikuga, kuna seda on lihtne õppida, selle süntaks on lihtsam ja õppematerjalid paremad.
 Ehitate käivitustoodet ja kontrollite oma hüpoteesi, kuna see on hea rakenduste kiireks arendamiseks ja Laraveli arendajad neid on lihtne leida.
 
  Symfony on parim valik, kui: 
  Ehitate keerukat ettevõtterakendust, kuna see on väga skaleeritav, hooldatav ja hästi struktureeritud.
 Ehitate suure pikaajalise projekti rännet, kuna Symfonyl on järgmise kuue aasta jooksul prognoositavad väljaandmisplaanid, seega on vähem tõenäoline, et üllatusi tuleb.


    
    
    
        
            
                
                    
                        
                            Pinterest disaineritele - ülevaade
                            Tööriistad Ja Õpetused
                            
                        
                        
                            
                        
                    
                
                
                    
                        
                            
                        
                        
                            Suurendage oma kasutajasõbralikkust nende edukate interaktsioonide kujundamise põhimõtete abil
                            Ux Disain
                            
                        
                    
                
            
        
    
    
    
    
        

	
		
			
				
					Lemmik Postitused
					
						
						
							Äriplaani anatoomia
						
					

						
						
							Ladina-Ameerika ühinemiste ja ühinemiste parimad tavad
						
					

						
						
							Tarkvara kulude hindamine agiilses projektijuhtimises
						
					

						
						
							Andekus pole kaup
						
					

						
						
							Veebi juurdepääsetavus: miks W3C standardeid sageli eiratakse
						
					
				
			
			
				
					 
					
						
						
							Bränding on surnud, CX Design on kuningas
						
					

						
						
							Chatbot UX - disaininõuanded ja kaalutlused
						
					

						
						
							Uus ettevõtluslaine
						
					

						
						
							Optimeeritud järjestikune keskmine kvantimise teisendus
						
					

						
						
							Kasutajauuringute väärtus
						
					
					
				
			
			
				
					Lemmik Postitused
					 .net tuumveebi api
kui paljud ettevõtted kasutavad sharepointi
gestalt läheduse printsiip
awsi sertifitseeritud lahenduste arhitekti kaastöötaja eksam
millised ülesanded on seotud andmebaasitabeli kujundamisega?
milline moodul võib öelda, kui kaua teie koodi käivitamine aega võttis?
millised on cfo kohustused
 
							
					
				
			
			
				
					Kategooriad
					Tooteinimesed Ja Meeskonnad
Ux Disain
Protsess Ja Tööriistad
Andmeteadus Ja Andmebaasid
				
			
		
	




	
		
			© 2022 | Kõik Õigused Kaitstud
			portaldacalheta.pt