Σήμερα, όταν ξεκινάτε ένα νέο έργο, μία από τις βασικές αποφάσεις είναι να επιλέξετε το σωστό πλαίσιο. Είναι δύσκολο να φανταστεί κανείς τη δημιουργία μιας σύνθετης εφαρμογής ιστού από το μηδέν σήμερα χωρίς καμία.
Πολλές δημοφιλείς γλώσσες για ανάπτυξη ιστοσελίδων έχουν το «προεπιλεγμένο» πλαίσιο τους, όπως το Ruby on Rails για το Ruby ή το Django για το Python. Ωστόσο, η PHP δεν έχει μια τέτοια προεπιλογή και έχει πολλές δημοφιλείς επιλογές για να διαλέξετε.
Σύμφωνα με Τάσεις Google και GitHub , τα πιο δημοφιλή πλαίσια PHP είναι Συμφωνία με 13,7k αστέρια και Laravel με 29k αστέρια (τη στιγμή της σύνταξης αυτού του άρθρου).
Σε αυτό το άρθρο, θα συγκρίνω αυτά τα δύο πλαίσια και θα σας δείξω πώς να εφαρμόσετε απλές, καθημερινές λειτουργίες με κάθε ένα. Με αυτόν τον τρόπο, μπορείτε να συγκρίνετε τον κώδικα παραδειγμάτων πραγματικής ζωής δίπλα-δίπλα.
Αυτό το άρθρο προϋποθέτει ισχυρές δεξιότητες PHP και κατανόηση του αρχιτεκτονικού παραδείγματος του MVC, αλλά δεν απαιτείται προηγούμενη εμπειρία με το Symfony ή το Laravel.
Όταν μιλάμε για Laravel, αναφερόμαστε στο Laravel έκδοση 4 και μετά. Το Laravel 4 κυκλοφόρησε το 2013 και αντιπροσώπευε μια πλήρη επανεγγραφή του πλαισίου. Η λειτουργικότητα του πλαισίου αποσυνδέθηκε σε ξεχωριστά στοιχεία, τα οποία διαχειρίστηκαν με το Composer, αντί για όλα να βρίσκονται σε ένα μοναδικό τεράστιο αποθετήριο κώδικα.
Ο Laravel δηλώνεται ως πλαίσιο ταχείας ανάπτυξης με μια απλή και όμορφη σύνταξη που είναι εύκολο να μάθει, να διαβάσει και να συντηρήσει. Είναι το πιο δημοφιλές πλαίσιο το 2016. Σύμφωνα με Τάσεις Google , είναι τρεις φορές πιο δημοφιλές από άλλα πλαίσια και άλλα GitHub , έχει δύο φορές περισσότερα αστέρια από τους ανταγωνιστές.
Το Symfony 2 κυκλοφόρησε το 2011, αλλά δεν πρέπει να συγχέεται με το Symfony 1, το οποίο ήταν ένα εντελώς διαφορετικό πλαίσιο με διαφορετικές βασικές αρχές. Ο Fabien Potencier δημιούργησε το Symfony 2 και η τρέχουσα έκδοση είναι 3.2, η οποία είναι μια σταδιακή έκδοση του Symfony 2. Επομένως, συχνά ονομάζονται απλά Symfony2 / 3.
Όπως το Laravel 4, το Symfony 2 έχει σχεδιαστεί ως ένα σύνολο αποσυνδεδεμένων στοιχείων. Υπάρχουν δύο πλεονεκτήματα εδώ: Μπορούμε να αντικαταστήσουμε οποιοδήποτε στοιχείο σε ένα έργο Symfony και μπορούμε να πάρουμε και να χρησιμοποιήσουμε οποιοδήποτε στοιχείο Symfony σε ένα έργο που δεν είναι Symfony. Τα στοιχεία Symfony μπορούν να χρησιμεύσουν ως εξαιρετικά παραδείγματα κώδικα και χρησιμοποιούνται σε πολλά έργα ανοιχτού κώδικα όπως Drupal, phpBB και Codeception. Στην πραγματικότητα, το ίδιο το Laravel χρησιμοποιεί τουλάχιστον 14 στοιχεία Symfony. Η κατανόηση της Symfony σας δίνει έτσι πολλά οφέλη όταν εργάζεστε με άλλα έργα.
ποια αρχή gestalt της αντιληπτικής οργάνωσης επεξηγείται στο παρακάτω παράδειγμα;
Και τα δύο πλαίσια έρχονται με προγράμματα εγκατάστασης και περιτυλίγματα διαθέσιμα μέσω του Ενσωματωμένος διακομιστής ιστού PHP .
Η εγκατάσταση της Symfony είναι τόσο απλή όσο η ακόλουθη:
# 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
Αυτό είναι! Η εγκατάσταση του Symfony διατίθεται στη διεύθυνση URL http://localhost:8000
.
Η διαδικασία εγκατάστασης του Laravel είναι σχεδόν η ίδια και τόσο απλή όσο και για το Symfony. η μόνη διαφορά είναι ότι εγκαθιστάτε το πρόγραμμα εγκατάστασης του Laravel μέσω του Composer:
# 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
Τώρα μπορείτε να επισκεφθείτε http://localhost:8000
και ελέγξτε την εγκατάσταση του Laravel.
Σημείωση: Τόσο το Laravel όσο και το Symfony τρέχουν από την ίδια θύρα localhost (8000) από προεπιλογή, επομένως δεν μπορείτε να έχετε αυτές τις προεπιλεγμένες παρουσίες να εκτελούνται ταυτόχρονα. Μην ξεχάσετε να σταματήσετε τον διακομιστή Symfony εκτελώντας php bin/console server:stop
πριν από την εκκίνηση του διακομιστή Laravel.
Αυτά είναι παραδείγματα μιας βασικής εγκατάστασης. Για πιο προηγμένα παραδείγματα χρήσης, όπως είναι η δυνατότητα διαμόρφωσης έργων με τοπικούς τομείς ή η εκτέλεση πολλαπλών έργων ταυτόχρονα, και τα δύο πλαίσια παρέχουν πλαίσια Vagrant:
Το Symfony χρησιμοποιεί το YAML ως σύνταξη για τον καθορισμό της διαμόρφωσής του. Η προεπιλεγμένη διαμόρφωση βρίσκεται στο app/config/config.yml
αρχείο και μοιάζει με το ακόλουθο παράδειγμα:
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%' # ...
Για να δημιουργήσετε μια διαμόρφωση συγκεκριμένη για το περιβάλλον, δημιουργήστε το αρχείο app/config/config_ENV.yml
που περιέχει τις βασικές παραμέτρους διαμόρφωσης. Ακολουθεί ένα παράδειγμα ενός config_dev.yml
αρχείο για το περιβάλλον ανάπτυξης:
imports: - { resource: config.yml } # ... web_profiler: toolbar: true # ...
Αυτό το παράδειγμα ενεργοποιεί το web_profiler
Συμφωνικό εργαλείο μόνο για το περιβάλλον ανάπτυξης. Αυτό το εργαλείο σάς βοηθά να κάνετε εντοπισμό σφαλμάτων και να σχεδιάσετε την εφαρμογή σας απευθείας στο παράθυρο του προγράμματος περιήγησης.
Στα αρχεία διαμόρφωσης, μπορείτε επίσης να παρατηρήσετε %secret%
κατασκευές. Μας επιτρέπουν να τοποθετούμε συγκεκριμένες για το περιβάλλον μεταβλητές στα ξεχωριστά parameters.yml
αρχείο. Αυτό το αρχείο θα μπορούσε να είναι μοναδικό σε κάθε υπολογιστή και δεν αποθηκεύεται υπό έλεγχο έκδοσης. Για έλεγχο έκδοσης, έχουμε ένα ειδικό parameters.yml.dist
αρχείο που είναι το πρότυπο για το parameters.yml
αρχείο.
Ακολουθεί ένα παράδειγμα του parameters.yml
αρχείο:
parameters: database_host: 127.0.0.1 database_port: null database_name: symfony database_user: root database_password: null secret: f6b16aea89dc8e4bec811dea7c22d9f0e55593af
Η διαμόρφωση Laravel φαίνεται πολύ διαφορετική από αυτή του Symfony. Το μόνο πράγμα που έχουν κοινό είναι ότι και οι δύο χρησιμοποιούν αρχεία που δεν αποθηκεύονται υπό έλεγχο έκδοσης (.env
στην περίπτωση Laravel) και ένα πρότυπο για τη δημιουργία αυτού του αρχείου (.env.example
). Αυτό το αρχείο έχει μια λίστα κλειδιών και τιμών, όπως το ακόλουθο παράδειγμα:
APP_ENV=local APP_KEY=base64:Qm8mIaur5AygPDoOrU+IKecMLWgmcfOjKJItb7Im3Jk= APP_DEBUG=true APP_LOG_LEVEL=debug APP_URL=http://localhost
Όπως το αρχείο Symfony YAML, αυτό για το Laravel είναι επίσης αναγνώσιμο από τον άνθρωπο και φαίνεται καθαρό. Μπορείτε επιπλέον να δημιουργήσετε .env.testing
αρχείο που θα χρησιμοποιηθεί κατά την εκτέλεση δοκιμών PHPUnit.
Η διαμόρφωση της εφαρμογής αποθηκεύεται σε .php
αρχεία στο config
Ευρετήριο. Η βασική διαμόρφωση αποθηκεύεται στο app.php
Το αρχείο και η διαμόρφωση για συγκεκριμένα στοιχεία αποθηκεύεται στο .php
αρχεία (π.χ. cache.php
ή mail.php
). Ακολουθεί ένα παράδειγμα ενός config/app.php
αρχείο:
'Laravel', 'env' => env('APP_ENV', 'production'), 'debug' => env('APP_DEBUG', false), 'url' => env('APP_URL', 'http://localhost'), 'timezone' => 'UTC', 'locale' => 'en', // ... ];
Οι μηχανισμοί διαμόρφωσης εφαρμογών της Symfony σάς επιτρέπουν να δημιουργείτε διαφορετικά αρχεία για διαφορετικά περιβάλλοντα. Επιπλέον, σας εμποδίζει να εισάγετε σύνθετη λογική PHP στη διαμόρφωση YAML.
Ωστόσο, μπορεί να αισθάνεστε πιο άνετα με την προεπιλεγμένη σύνταξη διαμόρφωσης PHP που χρησιμοποιεί ο Laravel και δεν χρειάζεται να μάθετε τη σύνταξη YAML.
Γενικά, μια εφαρμογή ιστού back-end έχει μια πρωταρχική ευθύνη: να διαβάζει κάθε αίτημα και να δημιουργεί μια απάντηση ανάλογα με το περιεχόμενο του αιτήματος. Ο ελεγκτής είναι μια κατηγορία που είναι υπεύθυνη για τη μετατροπή του αιτήματος στην απόκριση καλώντας τις μεθόδους εφαρμογής, ενώ ο δρομολογητής είναι ένας μηχανισμός που σας βοηθά να εντοπίσετε ποια κλάση ελεγκτή και μέθοδο πρέπει να εκτελέσετε για ένα συγκεκριμένο αίτημα.
Ας δημιουργήσουμε έναν ελεγκτή που θα εμφανίζει μια σελίδα ανάρτησης ιστολογίου που ζητήθηκε από το /posts/{id}
Διαδρομή.
Ελεγκτής
Post::findOrFail($id)]); } }
Δρομολογητής
Route::get('/posts/{id}', ' [email protected] ');
Ορίσαμε τη διαδρομή για GET
αιτήσεων. Όλα τα αιτήματα με το URI που αντιστοιχούν στο /posts/{id}
θα εκτελέσει το BlogController
ελεγκτή show
τη μέθοδο και θα περάσει την παράμετρο id
σε αυτήν τη μέθοδο. Στον ελεγκτή, προσπαθούμε να βρούμε το αντικείμενο του μοντέλου POST
με το περασμένο id
και καλέστε τον βοηθό Laravel view()
για απόδοση της σελίδας.
Στο Symfony, exampleController
είναι λίγο μεγαλύτερο:
getDoctrine()->getRepository('BlogBundle:Post'); $post = $repository->find($id); if ($post === null) { throw $this->createNotFoundException(); } return $this->render('BlogBundle:Post:show.html.twig', ['post'=>$post]); } }
Μπορείτε να δείτε ότι έχουμε ήδη συμπεριλάβει @Route('/posts/{id}”)
στον σχολιασμό, οπότε πρέπει απλώς να συμπεριλάβουμε τον ελεγκτή στο routing.yml
αρχείο διαμόρφωσης:
blog: resource: '@BlogBundle/Controller/' type: annotation prefix: /
Η λογική βήμα προς βήμα είναι η ίδια όπως στην περίπτωση του Laravel.
επιπτώσεις του χρώματος στα συναισθήματα
Σε αυτό το στάδιο, ίσως νομίζετε ότι ο Laravel είναι πολύ πιο καλός από το Symfony. Αυτό ισχύει στην αρχή. Φαίνεται πολύ καλύτερο και πιο εύκολο να ξεκινήσετε. Ωστόσο, στις πραγματικές εφαρμογές, δεν πρέπει να καλέσετε το Doctrine από τον ελεγκτή. Αντ 'αυτού, πρέπει να καλέσετε μια υπηρεσία που θα προσπαθήσει να βρει την ανάρτηση ή να ρίξει Εξαίρεση HTTP 404 .
Το Laravel αποστέλλεται με μια μηχανή προτύπου που ονομάζεται Λεπίδα και τα πλοία Symfony με Κλαδάκι . Και οι δύο κινητήρες προτύπων εφαρμόζουν δύο βασικά χαρακτηριστικά:
Και οι δύο δυνατότητες σάς επιτρέπουν να ορίσετε ένα βασικό πρότυπο με ανατρέψιμες ενότητες και θυγατρικά πρότυπα που γεμίζουν τιμές αυτών των ενοτήτων.
Ας εξετάσουμε ξανά το παράδειγμα μιας σελίδας ανάρτησης ιστολογίου.
// 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 %}
Δομικά, τα πρότυπα Blade και Twig είναι αρκετά παρόμοια. Και οι δύο δημιουργούν πρότυπα σε κώδικα PHP και λειτουργούν γρήγορα, και οι δύο υλοποιούν δομές ελέγχου, όπως if
δηλώσεις και βρόχους. Το πιο σημαντικό χαρακτηριστικό που έχουν και οι δύο κινητήρες είναι ότι ξεφεύγουν από την έξοδο από προεπιλογή, κάτι που βοηθά στην αποτροπή επιθέσεων XSS.
Εκτός από τη σύνταξη, η κύρια διαφορά είναι ότι το Blade σάς επιτρέπει να εισάγετε κώδικα PHP απευθείας στα πρότυπα σας και το Twig δεν το κάνει. Αντ 'αυτού, το Twig σάς επιτρέπει να χρησιμοποιείτε φίλτρα.
Για παράδειγμα, εάν θέλετε να κεφαλαιοποιήσετε μια συμβολοσειρά, στο Blade θα καθορίσετε τα εξής:
{{ ucfirst('welcome friend') }}
Στο Twig, από την άλλη πλευρά, θα κάνετε τα εξής:
{capitalize }
Στο Blade, είναι ευκολότερο να επεκταθεί κάποια λειτουργικότητα, αλλά το Twig δεν επιτρέπει άμεσο κώδικα PHP σε πρότυπα.
Οι εφαρμογές έχουν πολλές διαφορετικές υπηρεσίες και στοιχεία, με διάφορες αλληλεξαρτήσεις. Πρέπει να αποθηκεύσετε κάπως όλες τις πληροφορίες σχετικά με τα δημιουργημένα αντικείμενα και τις εξαρτήσεις τους.
Εδώ έρχεται το επόμενο συστατικό μας - Κοντέινερ σέρβις . Είναι ένα αντικείμενο PHP που δημιουργεί τις ζητούμενες υπηρεσίες και αποθηκεύει πληροφορίες σχετικά με τα δημιουργημένα αντικείμενα και τις εξαρτήσεις τους.
Ας εξετάσουμε το ακόλουθο παράδειγμα: Δημιουργείτε μια τάξη PostService
να εφαρμόσει μια μέθοδο που είναι υπεύθυνη για τη δημιουργία μιας νέας ανάρτησης ιστολογίου. Αυτή η τάξη εξαρτάται από δύο άλλες υπηρεσίες: PostRepository
, η οποία είναι υπεύθυνη για την αποθήκευση πληροφοριών στη βάση δεδομένων και SubscriberNotifier
, η οποία είναι υπεύθυνη για την ειδοποίηση των εγγεγραμμένων χρηστών σχετικά με τη νέα ανάρτηση. Για να λειτουργήσει, πρέπει να περάσετε αυτές τις δύο υπηρεσίες ως ορίσματα κατασκευαστή του PostService
ή, με άλλα λόγια, πρέπει να εισάγετε αυτές τις εξαρτήσεις.
Αρχικά, ας καθορίσουμε τις υπηρεσίες δειγματοληψίας μας:
repository = $repository; $this->notifier = $notifier; } public function create(Post $post) { $this->repository->persist($post); $this->notifier->notifyCreate($post); } }
Στη συνέχεια είναι η διαμόρφωση έγχυσης εξάρτησης:
# 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
Τώρα μπορείτε να ζητήσετε την υπηρεσία ταχυδρομείου σας οπουδήποτε στον κώδικα από το αντικείμενο Service Container. Για παράδειγμα, στον ελεγκτή θα μπορούσε να είναι κάτι τέτοιο:
// Controller file. $post variable defined below $this->get('blog.post_service')->create($post);
Το Service Container είναι ένα εξαιρετικό στοιχείο και βοηθά στη δημιουργία της εφαρμογής σας ακολουθώντας ΣΤΕΡΕΟΣ αρχές σχεδιασμού.
Σχετίζεται με: Έγχυση πραγματικής εξάρτησης με στοιχεία Symfony Παράδειγμα έγχυσης εξάρτησης Laravel
Είναι πολύ πιο εύκολο να διαχειριστείτε εξαρτήσεις στο Laravel. Ας εξετάσουμε το ίδιο παράδειγμα:
repository = $repository; $this->notifier = $notifier; } public function create(Post $post) { $this->repository->persist($post); $this->notifier->notifyCreate($post); } }
Εδώ έρχεται η ομορφιά του Laravel - δεν χρειάζεται να δημιουργήσετε διαμορφώσεις εξάρτησης . Το Laravel σαρώνει αυτόματα τις εξαρτήσεις για PostService
στους τύπους ορισμάτων του κατασκευαστή και τα επιλύει αυτόματα.
Μπορείτε επίσης να χρησιμοποιήσετε την ένεση στη μέθοδο του ελεγκτή σας για να χρησιμοποιήσετε PostService
με 'type-hinting' σε ορίσματα μεθόδου:
'Title', 'content' => 'Content']); $service->create($post); return redirect('/posts/'.$post->id); } }
Έγχυση εξάρτησης: Symfony εναντίον Laravel
Η αυτοανίχνευση του Laravel λειτουργεί τέλεια. Το Symfony έχει παρόμοια δυνατότητα που ονομάζεται « autowire 'Που είναι απενεργοποιημένο από προεπιλογή και θα μπορούσε να ενεργοποιηθεί προσθέτοντας autowire: true
στη διαμόρφωση εξάρτησής σας, αλλά απαιτεί κάποια διαμόρφωση. Ο τρόπος Laravel είναι απλούστερος.
Αντιστοίχιση Αντικειμένου (ORM)
Για να εργαστείτε με βάσεις δεδομένων, και τα δύο πλαίσια διαθέτουν δυνατότητες Object-Relational Mapping (ORM). Το ORM χαρτογραφεί εγγραφές από τη βάση δεδομένων σε αντικείμενα του κώδικα. Για να το κάνετε αυτό, πρέπει να δημιουργήσετε μοντέλα για κάθε τύπο εγγραφής (ή για κάθε πίνακα) στη βάση δεδομένων σας.
Η Symfony χρησιμοποιεί ένα έργο τρίτου μέρους Δόγμα να αλληλεπιδράσει με τη βάση δεδομένων, ενώ ο Laravel χρησιμοποιεί τη δική του βιβλιοθήκη Εύγλωττος .
Το Eloquent ORM εφαρμόζει το Μοτίβο ActiveRecord για να εργαστείτε με τη βάση δεδομένων. Σε αυτό το μοτίβο, κάθε μοντέλο γνωρίζει τη σύνδεση με τη βάση δεδομένων και μπορεί να αλληλεπιδράσει με αυτήν. Για παράδειγμα, μπορεί να αποθηκεύσει δεδομένα στη βάση δεδομένων, να ενημερώσει ή να διαγράψει μια εγγραφή.
Το δόγμα εφαρμόζει το Πρότυπο χαρτογράφησης δεδομένων , όπου τα μοντέλα δεν γνωρίζουν τίποτα για τη βάση δεδομένων. γνωρίζουν μόνο τα ίδια τα δεδομένα. Ένα ειδικό ξεχωριστό επίπεδο, EntityManager
, αποθηκεύει όλες τις πληροφορίες σχετικά με την αλληλεπίδραση μεταξύ μοντέλων και βάσεων δεδομένων και χειρίζεται όλες τις λειτουργίες.
Ας πάρουμε ένα παράδειγμα για να κατανοήσουμε τη διαφορά. Ας υποθέσουμε ότι το μοντέλο σας έχει ένα κύριο id
κλειδί, τίτλος, περιεχόμενο και συγγραφέας. ο Δημοσιεύσεις Ο πίνακας αποθηκεύει μόνο τον συντάκτη id
, οπότε πρέπει να δημιουργήσετε μια σχέση με το Χρήστες τραπέζι.
Δόγμα
Ας ξεκινήσουμε καθορίζοντας τα μοντέλα:
Εδώ, δημιουργήσαμε πληροφορίες χαρτογράφησης μοντέλου και τώρα μπορούμε να χρησιμοποιήσουμε ένα βοηθό για να δημιουργήσουμε τα stubs της μεθόδου:
php bin/console doctrine:generate:entities BlogBundle
Στη συνέχεια, ορίζουμε τις μεθόδους μετά την αποθήκευση:
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(); } }
Τώρα μπορείτε να καλέσετε αυτές τις μεθόδους από την υπηρεσία ή, για παράδειγμα, από 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);
Εύγλωττος
ο Χρήστης το μοντέλο αποστέλλεται με Laravel και ορίζεται από προεπιλογή, επομένως πρέπει να ορίσετε μόνο ένα μοντέλο για το Θέση .
belongsTo('AppUser', 'author_id'); } }
Αυτό είναι όλο για μοντέλα. Στο Eloquent, δεν χρειάζεται να ορίσετε ιδιότητες μοντέλου, καθώς τις δημιουργεί δυναμικά με βάση τη δομή του πίνακα βάσεων δεδομένων. Για να αποθηκεύσετε μια νέα ανάρτηση $post
στη βάση δεδομένων, πρέπει να πραγματοποιήσετε αυτήν την κλήση (για παράδειγμα, από τον ελεγκτή):
$post->save();
Για να βρείτε όλες τις αναρτήσεις ενός συγγραφέα με ένα συγκεκριμένο όνομα, η καλύτερη προσέγγιση θα ήταν να βρείτε έναν χρήστη με το όνομά του και να ζητήσετε αναρτήσεις όλων των χρηστών:
$posts = Post::whereHas('author', function ($q) { $q->where('name', 'Karim'); })->get();
ORM: Symfony εναντίον Laravel
Όσον αφορά το ORM, το Eloquent φαίνεται πολύ πιο φιλικό Προγραμματιστές PHP και πιο εύκολο να το μάθεις από το δόγμα.
Event Dispatcher εναντίον Middleware

Ένα από τα πιο σημαντικά πράγματα που πρέπει να κατανοήσετε για ένα πλαίσιο είναι ο κύκλος ζωής του.
Symfony και Event Dispatcher
Για να μετατρέψει ένα αίτημα σε απόκριση, το Symfony χρησιμοποιεί το EventDispatcher. Συνεπώς, ενεργοποιεί διαφορετικά συμβάντα κύκλου ζωής και ειδικούς ακροατές για τη διαχείριση αυτών των συμβάντων. Στην αρχή, αποστέλλει το kernel.request
συμβάν που περιλαμβάνει πληροφορίες αιτήματος. Ο κύριος προεπιλεγμένος ακροατής αυτού του συμβάντος είναι RouterListener
, ο οποίος καλεί το στοιχείο του δρομολογητή να βρει έναν κατάλληλο κανόνα διαδρομής για το τρέχον αίτημα. Μετά από αυτό, άλλα συμβάντα εκτελούνται βήμα προς βήμα. Οι τυπικοί ακροατές συμβάντων είναι ένας έλεγχος ασφαλείας, μια επαλήθευση διακριτικών CSRF και μια διαδικασία καταγραφής. Εάν θέλετε να προσθέσετε κάποια λειτουργικότητα στον κύκλο ζωής του αιτήματος, πρέπει να δημιουργήσετε ένα προσαρμοσμένο EventListener
και εγγραφείτε στο απαραίτητο συμβάν.
Laravel και Middleware
Το Laravel χρησιμοποιεί μια διαφορετική λύση: το middleware. Μου αρέσει να συγκρίνω το middleware με ένα κρεμμύδι: Η εφαρμογή σας έχει ορισμένα επίπεδα και ένα αίτημα περνά μέσα από αυτά τα επίπεδα στο δρόμο προς τον ελεγκτή και πίσω. Επομένως, εάν θέλετε να επεκτείνετε τη λογική της εφαρμογής σας και να προσθέσετε κάποια λειτουργικότητα στον κύκλο ζωής του αιτήματος, θα πρέπει να προσθέσετε ένα επιπλέον επίπεδο στη λίστα μεσαίου λογισμικού και το Laravel θα το εκτελέσει.
API REST
Ας προσπαθήσουμε να δημιουργήσουμε ένα βασικό παράδειγμα CRUD για τη διαχείριση μιας ανάρτησης ιστολογίου:
- Δημιουργία -
POST /posts/
- Διαβάστε -
GET /posts/{id}
- Ενημέρωση -
PATCH /posts/{id}
- Διαγραφή -
DELETE /posts/{id}
REST API στο Symfony
Η Symfony δεν διαθέτει μια εύκολη λύση για γρήγορη δημιουργία API REST, αλλά διαθέτει υπέροχα πακέτα τρίτων FOSRestBundle
και JMSSerializerBundle
.
Ας εξετάσουμε το ελάχιστο παράδειγμα λειτουργίας με FOSRestBundle
και JMSSerializerBundle
. Αφού τα εγκαταστήσετε και τα ενεργοποιήσετε στο AppKernel
, μπορείτε να ορίσετε στη διαμόρφωση δέσμης ότι θα χρησιμοποιήσετε τη μορφή JSON και ότι αυτό δεν χρειάζεται να συμπεριληφθεί στα αιτήματα διευθύνσεων URL:
#app/config/config.yml fos_rest: routing_loader: default_format: json include_format: false
Στη διαμόρφωση δρομολόγησης, πρέπει να καθορίσετε ότι αυτός ο ελεγκτής θα εφαρμόσει έναν πόρο REST:
mysql_set_charset
#app/config/routing.yml blog: resource: BlogBundleControllerPostController type: rest
Εφαρμόσατε μια σταθερή μέθοδο στο αποθετήριο στο προηγούμενο παράδειγμα. τώρα πρέπει να προσθέσετε μια μέθοδο διαγραφής:
// src/BlogBundle/Repository/PostRepository.php public function delete(Post $post) { $this->getEntityManager()->remove($post); $this->getEntityManager()->flush(); }
Στη συνέχεια, πρέπει να δημιουργήσετε ένα τάξη φόρμας για να αποδεχτείτε αιτήματα εισαγωγής και να τα χαρτογραφήσετε στο μοντέλο. Μπορείτε να το κάνετε χρησιμοποιώντας ένα βοηθό CLI:
php bin/console doctrine:generate:form BlogBundle:Post
Θα λάβετε έναν τύπο φόρμας που δημιουργήθηκε με τον ακόλουθο κωδικό:
add('title')->add('content'); } /** * {@inheritdoc} */ public function configureOptions(OptionsResolver $resolver) { $resolver->setDefaults([ 'data_class' => 'BlogBundleEntityPost', 'csrf_protection' => false ]); } /** * {@inheritdoc} */ public function getBlockPrefix() { return 'post'; } }
Τώρα ας εφαρμόσουμε τον ελεγκτή μας.
Σημείωση: ο κωδικός που θα σας δείξω δεν είναι τέλειος. Παραβιάζει κάποιες αρχές σχεδιασμού, αλλά θα μπορούσε εύκολα να αναθεωρηθεί. Ο κύριος σκοπός είναι να σας δείξω πώς να εφαρμόσετε κάθε μέθοδο, βήμα προς βήμα.
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); } }
Με FOSRestBundle
, δεν χρειάζεται να δηλώσετε μια διαδρομή για κάθε μέθοδο. απλώς ακολουθήστε τη σύμβαση με ονόματα μεθόδου ελεγκτή και JMSSerializerBundle
θα μετατρέψει αυτόματα τα μοντέλα σας σε JSON.
API REST στο Laravel
Πρώτον, πρέπει να ορίσετε διαδρομές. Μπορείτε να το κάνετε αυτό στο API
ενότητα των κανόνων διαδρομής για να απενεργοποιήσετε ορισμένα προεπιλεγμένα στοιχεία μεσαίου λογισμικού και να ενεργοποιήσετε άλλα. Το API
Το τμήμα βρίσκεται στο routes/api.php
αρχείο.
Στο μοντέλο, πρέπει να ορίσετε το $fillable
ιδιότητα για μεταβίβαση μεταβλητών στις μεθόδους δημιουργίας και ενημέρωσης του μοντέλου:
Τώρα ας ορίσουμε τον ελεγκτή:
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, χρησιμοποιείτε το FosRestBundle
, το οποίο τυλίγει σφάλματα στο JSON. Στο Laravel, πρέπει να το κάνετε μόνοι σας. Πρέπει να ενημερώσετε τη μέθοδο απόδοσης στο πρόγραμμα χειριστή Εξαίρεσης για να επιστρέψετε σφάλματα JSON για αναμενόμενα αιτήματα JSON:
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 εναντίον Laravel
Όπως μπορείτε να δείτε, για ένα τυπικό REST API, το Laravel είναι πολύ πιο απλό από το Symfony.
Επιλογή του νικητή: Symfony ή Laravel;
Δεν υπάρχει σαφής νικητής μεταξύ Laravel και Symfony, καθώς όλα εξαρτώνται από τον τελικό στόχο σας.
Το Laravel είναι μια καλύτερη επιλογή εάν:
- Αυτή είναι η πρώτη σας εμπειρία με το πλαίσιο, καθώς είναι εύκολο να μάθετε και έχει απλούστερη σύνταξη και καλύτερο εκπαιδευτικό υλικό.
- Δημιουργείτε ένα προϊόν εκκίνησης και ελέγχετε την υπόθεσή σας, καθώς είναι καλό για ταχεία ανάπτυξη εφαρμογών και Προγραμματιστές Laravel είναι εύκολο να βρεθούν.
Το Symfony είναι η καλύτερη επιλογή εάν:
- Δημιουργείτε μια πολύπλοκη εταιρική εφαρμογή, καθώς είναι πολύ επεκτάσιμη, διατηρήσιμη και καλά δομημένη.
- Δημιουργείτε μια μετανάστευση ενός μεγάλου μακροπρόθεσμου έργου, καθώς η Symfony έχει προβλέψιμα σχέδια κυκλοφορίας για τα επόμενα έξι χρόνια, οπότε είναι λιγότερο πιθανό να υπάρξουν εκπλήξεις.