Symfony bedste praksis (officiel anbefaling)

For et par dage siden afslørede Fabien Potencier via Sensio en e-bog, der samler bedste praksis og anbefalinger til udvikling af et Symfony-projekt. Formålet med dette dokument er at give et sæt råd i forbindelse med ph.iloSophia fra Symfony. Jeg vil forsøge kort at opsummere de 31 tips beskrevet på engelsk i dette indlæg.

Introduktion

Dette dokument begynder med nogle råd og et par sætninger, der skal inspirere os med dokumentet.

"Dette dokument er ikke et selvstudie"

Dette dokument er skrevet med den hensigt at blive læst af alle Symfony-udviklere. Både eksperter og neofytter.

"Refaktorer ikke dine apps"

Fra begyndelsen af ​​dokumentet er det specifikt forklaret, at vi efter denne læsning ikke bør opdatere og refaktorisere vores applikationer, for at det passer perfekt til Sensios mange anbefalinger. Vi kan derfor straks knytte forbindelsen til de første ideer, der er udviklet i dokumentet: Disse gode praksisser skal give os mulighed for at forenkle vores liv, samt forenkle gennemgang af koden. Til støtte for mine bemærkninger er tre grunde fremført:

• Dine eksisterende applikationer er ikke forkerte, de følger bare et andet sæt retningslinjer;
• En fuld kodebase refactoring er tilbøjelig til at introducere fejl i dine applikationer;
• Mængden af ​​arbejde brugt på dette kunne være bedre dedikeret til at forbedre dine tests eller tilføje funktioner, der giver reel værdi for slutbrugerne.

Opret et projekt

I kapitel 2, som omhandler, hvordan man deklarerer og opretter et Symfony-projekt, gives en første "Best Practice":

_Brug altid Composer. _Composer introducerede det grundlæggende i moderne PHP gennem dets afhængighedsopløsning. Takket være ham er afhængighederne registreret i filen composer.json vil blive løst og hjemsendt i dit projekt, så det er brugbart. Derudover kan der laves nemme opdateringer.

På denne måde kan du respektere den strukturelle organisering af et Symfony-projekt. (se side 8).

eksempler:

• app/cache vil gemme cachen;
• app/logfiler opbevare logs;
• app/ressourcer vil gemme skabelonerne samt de globale oversættelser til din ansøgning;
• src / gem dine applikationspakker;
• sælger / gemme dit projekts afhængigheder;
• Web/ vil gemme aktiverne (css, js, billeder osv.) samt frontfilen (app.php), så du efterfølgende kan omdirigere dine anmodninger til dine controllere.
  Som følge heraf en ny anbefaling om bundter. Uden at lave min egen analyse, som kunne sætte spørgsmålstegn ved philosophie fra Symfony (som jeg ikke ønsker), her er anbefalingen:

Opret en enkelt AppBundle-pakke til en applikation. Dette skyldes den måde, Symfony blev designet på. Hvert bundt skal være _stand-alone. _De bør derfor kunne leve selvstændigt og selvstændigt.

Jeg lader dig meditere over denne anbefaling...

Konfiguration

Det tredje kapitel giver os råd til at konfigurere dens applikation. Nogle konfigurationselementer kan variere fra et udviklingssystem til et produktionssystem.

Som anbefalingen indikerer, skal du derfor definere konfigurationen relateret til din infrastruktur i filen app/config/parameters.yml.

Omvendt vil den konfiguration, der er specifik for dit projekt, som vil være statisk, blive erklæret i app/config/config.yml.

Derudover filen parameters.yml bør ikke versioneres. Dette er filen parameters.yml.dist hvem skulle være. Det er denne fil, der giver dig grundlæggende muligheder for at konfigurere din applikation. (anbefaling side 12).

Som et resultat vil filen _app/config/config.yml _selv fungerer som en anbefaling.

Indstil konfiguration relateret til din applikation i app/config/config.yml
Efter denne anbefaling er det dog tilrådeligt at generere en fil config.yml, config_dev.yml og en fil config_prod.yml. Disse filer er beregnet til at gemme konstanterne, der er specifikke for udviklingsmiljøet og produktionsmiljøet.
Vi skal betragte en værdi som konstant, når dens værdi ændrer sig meget lidt.

Afhængighedsindsprøjtning

Her er vi ! I tredje kapitel er en anbefaling detaljeret om brugen af ​​afhængigheder. Jeg råder dig til at læse denne anbefaling, hvis min forklaring forekommer dig vag.

Denne anbefaling handler om at injicere tjenester i tjenester. Sensio anbefaler at deklarere dem i en fil src/AppBundle/Resources/config/services.yml.

Jeg inviterer dig også til at læse min artikel om afhængighedsinjektion og hvordan man begrænser brugen af ​​superservicebeholderen.

Erklær intern logik

Kapitel 4 omhandler organisering af din ansøgning. Afhængig af dine behov vil organisationen være forskellig. For globale og ikke-erhvervsmæssige funktioner anbefaler Sensio at placere dem i en mappe utils eller bare tag dem ud af dit bundt og læg det i en separat mappe. Herefter anbefales det kraftigt, at du erklærer din klasse som en service. En ny anbefaling er givet for at hjælpe os med at erklære dem.

Navnet på din tjeneste skal være så kort som muligt, ideelt set et enkelt ord.

Valg af filformat

Da jeg er særligt knyttet til Yaml-formatet i Symfony, forestiller jeg mig, at dette punkt vil skabe uenighed. Sensio anbefaler kompromisløst at bruge Yaml-formatet i applikationer. De udviklede bundter er delt mellem to formater: XML og Yaml.

Sensio besluttede at anbefale sidstnævnte, simpelthen fordi det er mere " brugervenlig ". Brug af et andet format vil ikke ændre den måde, din applikation fungerer på.

Definer ikke en variabel for deklarationen af ​​dine tjenester

Dette er en praksis, som du vil se meget i visse bundter, og alligevel advarer Sensio dig. Her er eksemplet givet i kogebog :

1 2 3 4 5 6 7 8

#app/config/services.yml # service definition med klassenavneområde som parameter parametre: slugger.class: AppBundleUtilsSlugger tjenester: slugger: klasse: "%slugger.class%"

Her er eksemplet på en ubrugelig kode. At erklære klassen til brug for en tjeneste er en fejl, da denne variabel muligvis kan bruges andre steder i koden. Derudover, og det er årsagen givet af Sensio, tynger det oprettelsen af ​​tjenesten.

Valget af ORM

Sensio anbefaler brugen af ​​Doctrin ORM i Symfony. Da den er en Doctrine-bruger, er integrationen i Symfony meget avanceret. Dette resulterer i en anbefaling, som relancerer den logiske organisering af vores projekter. Enhedserklæring skal holde logikken inde i et bundt. Se eksempel på side 18.

Erklæring af kortlægningen

Deklarationen af ​​Doktrinkortlægningen skal helst udføres takket være de anmærkninger, som anbefales inden for rammerne af Doktrin men også til andre anvendelser.

Brug annoteringer til at erklære enhedstilknytning.
Et eksempel er givet på side 19.

Montering af armaturer

Sensio råder uden at fremsætte det, at opsætte armaturer. For de uindviede er disse datasæt, der som standard vil blive brugt til at starte applikationen, før den overhovedet sættes i produktion.

Kodningsstandarder (slutningen af ​​kapitel 4)

Dette er en del, som Sensio underligt nok næsten har formørket. siger jeg underligt, da det er en vigtig del for mig.

Symfony er kodet i overensstemmelse med PSR1- og PSR2-standarderne. Disse standarder skal fremmes i fællesskabet af Symfony-udviklere, men også hos PHP-udviklere. Symfony har postet en artikel for at samle og fremhæve " Kodningsstandarder ". Lederen af ​​Sensio, Fabien Potencier har også lagt et værktøj på GitHub til at udføre kontrol af overholdelse af standarder.

Controllere

Når det kommer til controllere, er Symfonys philosophie "tynde controllere og fede modeller". Det betyder, at controllere skal forblive lette. Hver metode (handling), der vil blive tilgået via en rute, repræsenterer en handling. Koden for hver af disse metoder skal være "light" og kalde og koordinere handlinger. Disse andele skal være i tjenester.

Denne model præsenterer en controller som bruger applikationskoder/dele.

En controller skal følge nogle få regler

• En controller må maksimalt have 5 variable.
• En controller har maksimalt 10 handlinger.
• Hver handling må maksimalt indeholde 20 linjer.
  • En metode kan indeholde mere end 20 linjer, forudsat at den anvendte kode ikke kan faktoriseres.
    

    En controller bør arve Sensios FrameworkBundle-basiscontroller og bruge annoteringer til at administrere ruter, caching og sikkerhed.

    Det anbefales at bruge annoteringer, men brugen af ​​XML, YAML eller PHP er også gyldig. Ansøgningen må kun bruge et enkelt format.

Brug ikke @Skabelonen

Dette er en anbefaling til de mindre uventede, og alligevel er forklaringen særlig kraftfuld.

Brug ikke @Template()-annotationen til at konfigurere skabelonen, der bruges af controlleren
Forklaringen er enkel, @Template bruger en TemplateListener, som kaldes når begivenheden kernel.view kastes.
Under udarbejdelsen af ​​dette dokument blev der udført en test. Brugen af ​​@Template tager 26 ms før lancering af generationen, hvorimod for den samme side, som ville være blevet genereret ved hjælp af " $this->render(...) », ventetiden på 5 millisekunder.

Brug ParamConverter-annotering

Brugen af ​​denne annotering gør det muligt at automatisere hydreringen af ​​en enhed.

Det er godt at bruge ParamConverter-tricket, når det er enkelt og bekvemt.

skabeloner

Kapitel 6 beskriver skabelongenereringen. Det er uden besvær _hvad dokumentet giver os i kølvandet på flere anbefalinger.

• Brug Twig-skabelonmotoren
  Sensio anbefaler Twig af mange grunde. Udover at være en motor meget brugt af PHP-fællesskabet, både af PHP-udviklere fra starten, kun af Symfony-udviklere og andre rammer. Enkelhed lægges vægt på, og promoveringen af ​​deres produkt er tydeligt synlig. Endelig garanterer Sensio support til Symfony op til version 3. Du kan også finde de første overgange, du skal lave for at forberede din kode til at migrere til version 3.
• Gem ansøgningsskabeloner i app/ressourcer/visninger.
  Som standard er udviklere blevet vant til at gemme deres skabeloner i mappen Ressourcer af hvert bundt. Dette er ikke en dårlig ting, men Fabien Potencier anbefaler at gemme de globale skabeloner til din applikation i mappen nævnt ovenfor.
• Definer dine Twig extensions i AppBundle/Twig og konfigurere tjenesterne i app/config/services.yml.
  Twig extensions lider under dårligt udsyn. Disse udvidelser, selvom de er meget nyttige, bruges nogle gange for systematisk. Sensio præsenterer denne del, som jeg finder væsentlig, som en måde at injicere forretningskode i sine skabeloner. Jeg anbefaler dig at læse, hvordan du erklærer en Twig-udvidelse.

Formularer

Kapitel 7 giver os instruktioner om brug af formularer.

• Definer dine formularer i PHP-klasser.
  Symfony giver mulighed for at generere PHP-klasser, hvilket tillader automatiseret generering af formularer for givne enheder. DET Formularer som de kaldes, tilbyder komplet integration. Ændringen af ​​enheder assisteres. Derudover gør brugen af ​​Forms det muligt at deportere administrationen af ​​formularer fra skabeloner.
• Erklær ikke en knap for at sende dens formular.
  Dette er et overraskende punkt, da denne funktion blev introduceret i Symfony 2.5. På tidspunktet for skrivning af disse linjer er Symfony 2.6 ved at blive accepteret og er derfor endnu ikke officielt udgivet. Vi kan derfor rejse nogle spørgsmål om nytten af ​​denne funktionalitet, den bør ikke bruges!Tilføj knapper i skabeloner i stedet for i formularer, hvorfor?
  I sin forklaring forklarer Sensio-teamet, at selvom denne funktion forbliver "brugervenlig" og at det forenkler implementeringen af ​​formularer, forbliver visse funktionaliteter begrænsede.
  Eksempel, hvis du tilføjer en knap af typen indsende med en "Opret" etiket kan denne formular ikke genbruges til en redigeringsside. Du skal så deklarere din blanket som en service for at udføre en arv, hvilket ikke anbefales lidt længere nede.
• Brug ikke Twig-funktioner form() og _formStart().
  En del dedikeret til gengivelse af skabeloner er blevet oprettet. Hun lærer os, at brugen af ​​Twig fungerer form() og _ form_start()_ er forældet. Endnu en gang er dette en fejl for mig, da disse funktioner først for nylig har været tilgængelige.
  I Symfony er der flere måder at gengive en formular på. Af de forskellige måder at gengive, er den bedste måde en, der tilbyder maksimal fleksibilitet.
  Brug af Twig-funktionerne ovenfor giver kun ringe fordel. Sensio taler om øget læsbarhed ved brug af native HTML-tags. På trods af dette argument repræsenterer dette en lille fordel... Meget lille!

Erklær dine formularer som tjenester

Formularer er PHP-klasser, hvilket betyder, at de kan erklæres som en tjeneste. Du vil være i stand til at se denne metode i bundterne af FriendsOfSymfony. Denne metode anbefales ikke af Sensio undtagen i visse tilfælde, som jeg citerer nedenfor:

• Hvis du vil genbruge eksisterende formularer. Opsætning af arv mellem to former gør det muligt at begrænse omskrivningen af ​​alle attributterne.
• Hvis vi ønsker at indlejre samlinger af enheder.
  Brugen af ​​formularer som tjenester i tilfælde af en tilføjelses- eller redigeringsformular anbefales ikke, fordi brugen af ​​en tjeneste indlæser @beholder. Desuden vil det være svært at forstå, at denne service bruges af en controller.

Vedhæft (binder) dens former

Sensio begyndte for nylig en konstant migrering af Symfony2-kode til fremtidig Symfony3-kode. Blandt listen over ændringer, der kan foretages (du kan finde dem alle i UPGRADE-3.md), er den nye løsning til bindemiddel anmodningen sendt af en formular med formular som blev skabt. Den nye metode er beskrevet på side 21 i Best Practices.

Indtal det præsenterede uddrag:

1 2 3 4 5 6 7 8 9 10 11 12 13

offentlige funktion nyAction(Anmod $request) { // byg din formular $form->handleRequest($request); if ($form->isSubmitted() && $form->isValid()) { $em = $ dette->container->hent("doctrine.orm.default_entity_manager"); $em->persist($post); $em->flush(); afkast $ dette->omdirigere($ dette->genererUrl("admin_post_show"), matrix("id" => $post->getId())); } }

Internationalisering

Formålet med internationaliseringsmodulet er at oversætte indholdet fra et sprog til et andet, afhængigt af regionen eller brugerens sprog. Mere end anbefalingersdata er dette kapitel blevet skrevet mere for at vise mulighederne på denne del, som altid forbliver følsom.

I kapitel 8 beskriver redaktørerne, hvordan man aktiverer oversættelse.

hvad med formatet

Symfony tilbyder et væld af oversættelsesformater:

• PHP
• Qt
• .po
• .mo
• JSON
• CSV
• Ini
• og mange andre
  

  Brug XLIFF-formatet til dine oversættelsesfiler.
  Dette citat er naturligvis en Sensio-anbefaling. Ja men hvorfor? Vi får et kort og præcist svar.
  Blandt alle de understøttede formater er det kun XLIFF-formatet og gettext-formatet, der understøttes af professionelle oversættelsesværktøjer. Da XLIFF er baseret på XML, drager det fordel af indholdsvalidering.
  Symfony 2.6 bringer en ny funktion, der giver dig mulighed for at "kommentere" (tilføje noter) i dine XLIFF-filer. Dette er en stor nyhed, fordi genereringen af ​​oversættelsesfiler kan give problemer for oversættere med at forstå betydningen af ​​en sætning eller konteksten, den bruges i. Kort sagt, XLIFF er godt!

Hvor skal vores oversættelsesfiler opbevares?

Dette spørgsmål introducerer en Bedste praksis. Sensio anbefaler at gemme vores filer i app/ressourcer/oversættelser.

Normalt plejede vi at gemme vores oversættelser i hver af vores bundter. Det var ikke en dårlig ting, men oversættelser betragtes generelt som globale dele af vores apps, ligesom globale skabeloner, og det er derfor Sensio anbefaler, at vi gemmer dem i app.

Hvordan oversætter man vores applikationer?

Brug altid nøgler til at oversætte dit indhold.
På dette Bedst, Jeg vil ikke give min mening til kende, da jeg har ringe mulighed for at oversætte ansøgninger. Sensio råder til, at for at oversætte et ord som "Brugernavn", skal du bruge en nøgle som f.eks label.brugernavn.

Et eksempel er givet på side 35.

Sikkerhed

Kapitel 9 i bogen, omhandler en central del af Symfony; sikkerhed !

Symfony er designet til nemt at konfigurere og autentificere brugere, der gerne vil oprette forbindelse til vores applikationer. Denne del er meget kompleks og fuld af detaljer, så det er en grov oversigt. Du kan finde mere dokumentation på den dedikerede side.

Erklær dine firewalls

Konfigurationsmulighederne skal indtastes i filen sikkerhed.yml som er i app/konfig.

Medmindre du har to forskellige forbindelser til din applikation (system og brugere), anbefaler vi kun at bruge én indgangsfirewall med den anonyme indstilling aktiveret.
Wow wow wow! Vent, jeg ankommer til Symfony, jeg forstod ingenting!

Hvad er en firewall?

Du kan finde en artikel lavet i Wanadev om, hvordan man deklarerer og sætter indbygget godkendelse på Symfony. I denne artikel er det detaljeret, hvad der er en firewall.

En enkelt firewall? Hvorfor en ?

Hvis du lige har læst artiklen, der er linket til ovenfor, har du måske bemærket, at flere firewalls er blevet erklæret.

I den givne artikel var de tre navne dev, main et Logge på. På trods af dette overholdes den givne regel, kun en firewall kan betragtes som en gateway.

• dev : denne firewall tillader debug-bar at vise.
• main : denne firewall er vores INDGANG. Anonyme brugere vil være i stand til at logge ind, som om de ville respektere reglen. Alle ruter, der begynder med /, vil bruge denne post.
• Logge på : det er en firewall. Dette vil være vores gateway i et enkelt tilfælde: hvis vi vil oprette forbindelse. Dette er vigtigt for at have adgang til en login-formular.
  Reglen er derfor overholdt.

Definer en kodning

Kodning af adgangskoder er en nøglebeslutning. Der findes flere algoritmer, som f.eks sha (sha1, sha256, sha512, md5...).

Når du erklærer en kodning (se hvordan du deklarerer en kodning), kan der angives tre parametre.

• Krypteringsalgoritmen (standard: sha512);
• Antallet af iterationer (som standard: 5000);
• Kodningen er base64 for den kodede adgangskode (standard: sand).
  På trods af disse standardværdier, som jeg inviterer dig til at ændre for at ændre dem til dine applikationer. Sensio anbefaler også at bruge algoritmen bcrypt.

  Brug bcrypt-kodning til at kryptere brugeradgangskoder.
  Sensio forklarer, hvordan man bruger bcrypt. Dette omfatter en saltning værdi. Dette begrænser angreb og er mere modstandsdygtigt over for angreb af brute-force-typen. Du kan finde flere detaljer i Wikipedia-artiklen ovenfor.

Indstil tilladelser

Under en forbindelse registrerer Symfony, hvilken firewall der skal bruges. Efterfølgende, og selv før adgang til controlleren, udføres en adgangskontrol. De er defineret i filen sikkerhed.yml,

Sensio anbefaler:

1. beskytte vores "edge URL-mønstre", forstå vores globale mønstre (eksempel: /admin);
2. Brug anmærkninger @Sikkerhed så meget som muligt ;
3. Tjek rettighederne for en bruger via tjenesten sikkerhedskontekst (siden Symfony 2.6 har tjenesten udviklet sig, se her);
4. Definer vælgere for nemt at styre trafiksikkerheden;
5. Brug ACL at administrere objekt- og brugerrettigheder.

Brug @Security-annoteringer

Sensio anbefaler at bruge @Security-annotationen.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

brug SensioBundleFrameworkExtraBundleKonfigurationR; brug SensioBundleFrameworkExtraBundleKonfigurationSikkerhed; // ... / ** * Viser en formular til at oprette en ny post-enhed. * @Vej("/ny", navn="admin_post_ny") * @Sikkerhed("has_role('ROLE_ADMIN')") */ offentlige funktion nyAction() { // ... }

Brug udtryk til at gøre begrænsninger mere komplekse

Sensio forklarer os, at denne annotation også gør det muligt at generere mere komplekse forhold, såsom en sammenligning af to attributter mellem to objekter. Denne annotation kan kræve brug af ParamConverter.

Du kan finde mere information i dokumentet:

• Generer udtryk
• Konverter attributter til objekter

Adgangssikkerhed i Twig

Hvis du ønsker at sammenligne den tilsluttede bruger med brugeren af ​​et objekt, kan du tilgå fra Twig the bruger I gang.

1 2 3

{% if app.bruger … %} ... {% endif %}

Administrer din sikkerhed nemt

Håndtering af sikkerhed er ofte en følsom del, og organisering af vores kode er en væsentlig del af succesfuld sikring af vores applikation. Brugen af Vælgerne kan varmt anbefales. Andre måder at organisere din kode på kan overvejes. For eksempel kan vi overføre en beslutning til en metode fra vores enhed.

Du kan se Sensio-eksemplet på side 40.

Denne del er meget lidt detaljeret i forhold til de muligheder, som Symfony tilbyder. Jeg råder dig til at læse lidt mere dokumentation om denne del, hvis du står med en sikkerhedsopgave.

Webaktiver

Aktiver giver os mulighed for at administrere ressourcer såsom Javascript, CSS, fos-skrifttyper, billeder... så de er tilgængelige fra dine sider.

Dine aktiver skal gemmes i web/mappen
På denne måde kan du indlæse dine ressourcer i dine skabeloner på denne måde:

1 2	<link rel="stilark" href=« {{ asset(‘css/bootstrap.min.css’) }}«  /> <script src=« {{ asset(‘js/jquery.min.js’) }}« ></script>

Behold den offentlige webmappe og alt, der er gemt i den.

Brug Assetic

Assetic har flere interesser, såsom filkompilering. For eksempel, Less, Sass, TypeScript-filer... Af denne grund, mappen web kan ikke indeholde filer såsom filer .mindre.

Brug Assetic til at kompilere, kombinere og formindske dine aktiver, medmindre du bruger GruntJS.

Lær mere om Assetic

Assetic er et komplet værktøj på trods af nogle ulemper. Du kan finde dokumentation om dette modul ved at bruge nedenstående links:

• Brug Assetic
• Formindsk CSS og JS
• Komprimer billeder
• Se den officielle dokumentation

Opsæt tests

Test er anerkendt af de fleste udviklere som essentielt. Alligevel implementerer kun et mindretal dem.

Vi vil se, hvordan Sensio råder os til at udføre vores test.

Udfør enhedstest

Enhedstest bruges til at udføre funktionelle test, som igen tester logikken i din applikation. Symfony har ikke bestemt nogle særlige værktøjer til at teste dine tests. Redskaberne PHPUnit et PhpSpec er citeret.

Udfør funktionelle tests

Det er vigtigt at skabe gode scenarier for dine funktionelle tests, og alligevel støder udviklere hurtigt ind i problemer med at implementere dem.

Definer en funktionstest for at teste, om din side er indlæst korrekt.

Forsøg at bruge hårdkodede URL'er i stedet for at generere dem gennem generatoren.

Test JavaScript-funktionalitet

Mange værktøjer findes som Mink (et PHPUnit-bibliotek) og CasperJS.

Generer datasæt

Dette er ofte et problem for udviklere, der genererer datasæt.

Sensio anbefaler brug af biblioteker faker et Alice.

Konklusion

Denne artikel er taget fra Bedste praksis for Symfony. Selvom den forbliver enkel, har denne artikel til formål at dissekere de 50 sider med råd for at vejlede nye Symfony-udviklere.