Symfony beste praksis (offisiell anbefaling)
Webbyrå » Digitale nyheter » Symfony beste praksis (offisiell anbefaling)

Symfony beste praksis (offisiell anbefaling)

For noen dager siden avduket Fabien Potencier via Sensio en e-bok som samler beste praksis og anbefalinger for å utvikle et Symfony-prosjekt. Hensikten med dette dokumentet er satt sammen fra anbefalinger lagt ut av fellesskapet, og er å gi et sett med råd relatert til philoSophia fra Symfony. Jeg skal prøve å kort oppsummere de 31 tipsene som er beskrevet på engelsk i dette innlegget.

Introduksjon

Dette dokumentet begynner med noen råd og noen få setninger ment å inspirere oss med dokumentet.

"Dette dokumentet er ikke en veiledning"

Dette dokumentet ble skrevet med den hensikt å bli lest av alle Symfony-utviklere. Både eksperter og neofytter.

"Ikke refaktoriser appene dine"

Fra begynnelsen av dokumentet er det spesifikt forklart at etter denne lesingen bør vi ikke oppdatere og refaktorisere applikasjonene våre for at de skal passe perfekt med Sensios flere anbefalinger. Vi kan derfor umiddelbart knytte til de første ideene utviklet i dokumentet: disse gode praksisene skal tillate oss å forenkle livene våre, samt forenkle kodegjennomgang. For å støtte mine bemerkninger er tre grunner fremmet:

  • Dine eksisterende applikasjoner er ikke feil, de følger bare et annet sett med retningslinjer;
  • En fullstendig kodebase refactoring er utsatt for å introdusere feil i applikasjonene dine;
  • Mengden arbeid som brukes på dette kan være bedre dedikert til å forbedre testene dine eller legge til funksjoner som gir reell verdi for sluttbrukerne.

Lag et prosjekt

I kapittel 2 som omhandler hvordan man deklarerer og oppretter et Symfony-prosjekt, er en første "Best Practice" gitt:

_Bruk alltid Composer. _Composer introduserte det grunnleggende om moderne PHP gjennom sin avhengighetsoppløsning. Takket være ham, er avhengighetene registrert i filen komponist.json vil bli løst og repatriert i ditt prosjekt slik at det er brukbart. I tillegg kan enkle oppdateringer gjøres.

På denne måten kan du respektere den strukturelle organiseringen av et Symfony-prosjekt. (se side 8).

eksempler:

  • app/cache vil lagre cachen;
  • app/logger lagre logger;
  • app/ressurser vil lagre malene så vel som de globale oversettelsene for applikasjonen din;
  • src / lagre applikasjonspakkene dine;
  • Leverandør/ lagre prosjektets avhengigheter;
  • nett / vil lagre ressursene (css, js, bilder, etc.) samt frontfilen (app.php) slik at du senere kan omdirigere forespørslene dine til kontrollerene dine.
    Som et resultat, en ny anbefaling om bunter. Uten å gjøre min egen analyse som kan stille spørsmål ved philosophie fra Symfony (som jeg ikke vil ha), her er anbefalingen:

Lag en enkelt AppBundle-pakke for en applikasjon. Dette skyldes måten Symfony ble designet på. Hver bunt må være _frittstående. _De bør derfor kunne leve selvstendig og selvstendig.

Jeg lar deg meditere over denne anbefalingen ...

Konfigurasjon

Det tredje kapittelet gir oss råd om å konfigurere applikasjonen. Noen konfigurasjonselementer kan variere fra et utviklingssystem til et produksjonssystem.

Som anbefalingen tilsier, må du derfor definer konfigurasjonen knyttet til infrastrukturen din i filen app/config/parameters.yml.

Motsatt vil konfigurasjonen som er spesifikk for prosjektet ditt, som vil være statisk, deklareres i app/config/config.yml.

I tillegg filen parameters.yml skal ikke være versjonert. Dette er filen parameters.yml.dist hvem skal være. Det er denne filen som vil gi deg grunnleggende alternativer for å konfigurere applikasjonen din. (anbefaling side 12).

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

Angi konfigurasjon relatert til applikasjonen din i app/config/config.yml
Etter denne anbefalingen er det imidlertid tilrådelig å generere en fil config.yml, config_dev.yml og en fil config_prod.yml. Disse filene er ment å lagre konstantene som er spesifikke for utviklingsmiljøet og produksjonsmiljøet.
Vi må betrakte en verdi som konstant når verdien endres svært lite.

Avhengighetsinjeksjon

Her er vi ! I tredje kapittel er en anbefaling detaljert om bruk av avhengigheter. Jeg anbefaler deg å lese denne anbefalingen hvis forklaringen min virker vag for deg.

Denne anbefalingen handler om å injisere tjenester i tjenester. Sensio anbefaler å deklarere dem i en fil src/AppBundle/Resources/config/services.yml.

Jeg inviterer deg også til å lese artikkelen min om avhengighetsinjeksjon og hvordan du begrenser bruken av superservicebeholderen.

Erklær intern logikk

Kapittel 4 dekker organisering av søknaden din. Avhengig av dine behov vil organisasjonen variere. For globale og ikke-forretningsmessige funksjoner anbefaler Sensio å plassere dem i en mappe utils eller ganske enkelt ta dem ut av pakken og legg den i en egen mappe. Etter dette anbefales det sterkt at du erklærer klassen din som en tjeneste. En ny anbefaling er gitt for å hjelpe oss med å erklære dem.

Navnet på tjenesten bør være så kort som mulig, ideelt sett et enkelt ord.

Velge filformat

Siden jeg er spesielt knyttet til Yaml-formatet i Symfony, ser jeg for meg at dette punktet vil øke uenighet. Sensio anbefaler kompromissløst å bruke Yaml-formatet i applikasjoner. Buntene som er utviklet er delt mellom to formater: XML og Yaml.

Sensio bestemte seg for å anbefale sistnevnte rett og slett fordi det er mer " brukervennlig ". Bruk av et annet format vil ikke endre måten applikasjonen din fungerer på.

Ikke definer en variabel for deklarasjonen av tjenestene dine

Dette er en praksis du vil se mye i visse bunter, og likevel advarer Sensio deg. Her er eksemplet gitt i kokebok :

1
2
3
4
5
6
7
8
#app/config/services.yml
# service definisjon med klassenavnerom som parameter
parametere:
slugger.class: AppBundleUtilsSlugger
tjenester:
slugger:
klasse:
«%slugger.class%»

Her er eksempelet på en ubrukelig kode. Å erklære klassen som skal brukes for en tjeneste er en feil, siden denne variabelen muligens kan brukes andre steder i koden. I tillegg, og dette er grunnen gitt av Sensio, tynger det etableringen av tjenesten.

Valget av ORM

Sensio anbefaler bruk av Doctrine ORM i Symfony. Som en Doctrine-bruker er integreringen i Symfony veldig avansert. Dette resulterer i en anbefaling som relanserer den logiske organiseringen av våre prosjekter. Enhetserklæring må holde logikken inne i en bunt. Se eksempel på side 18.

Erklæring av kartleggingen

Erklæringen av Doktrinekartleggingen bør fortrinnsvis gjennomføres takket være merknadene som anbefales innenfor rammen av Doktrine men også for andre applikasjoner.

Bruk merknader for å deklarere enhetskartlegging.
Et eksempel er gitt på side 19.

Montering av inventar

Sensio råder uten å legge det frem, å sette opp inventar. For de uinitierte er dette datasett som vil bli brukt som standard for å starte applikasjonen før den i det hele tatt settes i produksjon.

Kodestandarder (slutten av kapittel 4)

Dette er en del som Sensio merkelig nok nesten har formørket. sier jeg rart siden det er en viktig del for meg.

Symfony er kodet i henhold til PSR1- og PSR2-standardene. Disse standardene må fremmes innenfor fellesskapet til Symfony-utviklere, men også med PHP-utviklere. Symfony har lagt ut en artikkel for å samle og fremheve " Kodningsstandarder ". Lederen for Sensio, Fabien Potencier har også satt et verktøy på GitHub for å utføre kontroller av samsvar med standarder.

Kontrollere

Når det kommer til kontrollere, er Symfonys philosophie "tynne kontrollere og fete modeller". Det betyr at kontroller bør forbli lette. Hver metode (handling) som vil få tilgang til via en rute, representerer en handling. Koden for hver av disse metodene må være "light" og kalle og koordinere handlinger. Disse aksjene må være i tjenester.

Denne modellen presenterer en kontroller som bruker applikasjonskoder/deler.

En kontrollør må følge noen få regler

  • En kontroller må ha maksimalt 5 variabler.
  • En kontroller har maksimalt 10 handlinger.
  • Hver handling må inneholde maksimalt 20 linjer.
    • En metode kan inneholde mer enn 20 linjer, forutsatt at koden som brukes ikke kan faktoriseres.

      En kontroller bør arve Sensios FrameworkBundle-basekontroller, og bruke merknader til å administrere ruter, hurtigbufring og sikkerhet.

      Bruk av merknader anbefales, men bruk av XML, YAML eller PHP er også gyldig. Applikasjonen skal bare bruke ett enkelt format.

Ikke bruk @Template

Dette er en anbefaling for de mindre uventede, og likevel er forklaringen spesielt kraftig.

Ikke bruk @Template()-kommentaren til å konfigurere malen som brukes av kontrolleren
Forklaringen er enkel, @Template bruker en TemplateListener som kalles når hendelsen kernel.view blir kastet.
Under produksjonen av dette dokumentet ble det utført en test. Bruken av @Template tar 26 ms før generasjonen startes, mens for den samme siden som ville blitt generert med " $this->render(...) », ventetiden på 5 millisekunder.

Bruk ParamConverter-annotering

Bruken av denne merknaden gjør det mulig å automatisere hydreringen av en enhet.

Å bruke ParamConverter-trikset er bra når det er enkelt og praktisk.

maler

Kapittel 6 beskriver malgenereringen. Det er uten _oppstyr _hva dokumentet gir oss i kjølvannet av flere anbefalinger.

  • Bruk Twig-malmotoren
    Sensio anbefaler Twig av mange grunner. Foruten å være en motor mye brukt av PHP-fellesskapet, både av PHP-utviklere fra bunnen av, bare av Symfony-utviklere og andre rammeverk. Enkelhet er vektlagt og markedsføringen av deres produkt er godt synlig. Til slutt garanterer Sensio støtte for Symfony opp til versjon 3. Du kan også finne de første overgangene du må gjøre for å forberede koden din til å migrere til versjon 3.
  • Lagre søknadsmaler i app/ressurser/visninger.
    Som standard har utviklere blitt vant til å lagre malene sine i mappen Ressurser av hver bunt. Dette er ikke en dårlig ting, men Fabien Potencier anbefaler å lagre de globale malene for applikasjonen din i mappen nevnt ovenfor.
  • Definer Twig-utvidelsene dine i AppBundle/Twig og konfigurere tjenestene i app/config/services.yml.
    Kvistforlengelser lider av dårlig sikt. Disse utvidelsene, men veldig nyttige, brukes noen ganger for systematisk. Sensio presenterer denne delen som jeg synes er viktig, som en måte å injisere forretningskode i malene sine. Jeg anbefaler deg å lese hvordan du erklærer en Twig-forlengelse.

Skjemaer

Kapittel 7 gir oss instruksjoner om bruk av skjemaer.

  • Definer skjemaene dine i PHP-klasser.
    Symfony gir muligheten til å generere PHP-klasser som tillater automatisert generering av skjemaer for gitte enheter. DE Skjemaer som de kalles, tilbyr fullstendig integrasjon. Modifisering av enheter assisteres. I tillegg gjør bruk av Forms det mulig å deportere administrasjonen av skjemaer fra maler.
  • Ikke erklær en knapp for å sende skjemaet.
    Dette er et overraskende poeng, siden denne funksjonen ble introdusert i Symfony 2.5. På tidspunktet for skriving av disse linjene er Symfony 2.6 i ferd med å bli akseptert og har derfor ennå ikke blitt offisielt utgitt. Vi kan derfor reise noen spørsmål om nytten av denne funksjonaliteten, den bør ikke brukes!Legg til knapper i maler i stedet for i Skjemaer, hvorfor?
    I sin forklaring forklarer Sensio-teamet at selv om denne funksjonen forblir "Brukervennlig" og at det forenkler implementeringen av skjemaer, forblir visse funksjoner begrenset.
    Eksempel, hvis du legger til en knapp av typen send med en "Opprett"-etikett kan ikke dette skjemaet gjenbrukes for en redigeringsside. Du må da oppgi skjemaet ditt som en tjeneste for å utføre en arv, noe som ikke anbefales litt lenger ned.
  • Ikke bruk Twig-funksjoner form() og _formstart().
    En del dedikert til gjengivelse av maler er satt opp. Hun lærer oss at bruken av Twig fungerer form() og _ form_start()_ er avviklet. Nok en gang er dette en feil for meg siden disse funksjonene bare nylig har vært tilgjengelige.
    I Symfony er det flere måter å gjengi et skjema på. Av de forskjellige måtene å gjengi, er den beste måten en som tilbyr maksimal fleksibilitet.
    Å bruke Twig-funksjonene oppført ovenfor gir liten fordel. Sensio snakker om økt lesbarhet ved bruk av native HTML-tagger. Til tross for dette argumentet, representerer dette en liten fordel... Veldig liten!

Erklær skjemaene dine som tjenester

Skjemaer er PHP-klasser som betyr at de kan deklareres som en tjeneste. Du vil kunne se denne metoden i buntene til FriendsOfSymfony. Denne metoden anbefales ikke av Sensio bortsett fra i visse tilfeller som jeg siterer nedenfor:

  • Hvis du ønsker å gjenbruke eksisterende skjemaer. Å sette opp arven mellom to former gjør det mulig å begrense omskrivingen av alle attributtene.
  • Hvis vi ønsker å bygge inn samlinger av enheter.
    Bruk av skjemaer som tjenester i tilfelle av et legg til eller redigeringsskjema anbefales ikke fordi bruken av en tjeneste laster inn @container. Dessuten vil det være vanskelig å forstå at denne tjenesten brukes av en kontroller.

Fest (perm) dens former

Sensio startet nylig en konstant migrering av Symfony2-kode til fremtidig Symfony3-kode. Blant listen over modifikasjoner som kan gjøres (du finner alle i UPGRADE-3.md), er den nye løsningen for bindemiddel forespørselen sendt av et skjema med skjema som ble opprettet. Den nye metodikken er beskrevet på side 21 i Beste praksis.

Stem utdraget som presenteres:

1
2
3
4
5
6
7
8
9
10
11
12
13
offentlig funksjon nyAksjon(Be om $request)
{
// bygg skjemaet ditt
$form->handleRequest($request);
if ($form->isSubmitted() && $form->isValid()) {
$em = $ dette->beholder->få(«doctrine.orm.default_entity_manager»);
$em->persist($post);
$em->flush();
retur $ dette->omdirigere($ dette->genererUrl(«admin_post_show»), matrise("id" => $post->getId()));
}
}

internasjonalisering

Hensikten med internasjonaliseringsmodulen er å oversette innholdet fra ett språk til et annet, avhengig av regionen eller språket til brukeren. Mer enn anbefalingsdata er dette kapittelet skrevet mer for å vise mulighetene på denne delen som alltid forblir sensitiv.

I kapittel 8 beskriver redaktørene hvordan du aktiverer oversettelse.

hva med formatet

Symfony tilbyr en rekke oversettelsesformater:

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

    Bruk XLIFF-formatet for oversettelsesfilene dine.
    Dette sitatet er åpenbart en Sensio-anbefaling. Ja, men hvorfor ? Et kort og presist svar er gitt til oss.
    Blant alle de støttede formatene er det kun XLIFF-formatet og gettext-formatet som støttes av profesjonelle oversettelsesverktøy. Siden XLIFF er basert på XML, drar det nytte av innholdsvalidering.
    Symfony 2.6 har en ny funksjon som lar deg "kommentere" (legge til notater) i XLIFF-filene dine. Dette er en stor nyhet, fordi generering av oversettelsesfiler kan føre til problemer for oversettere å forstå betydningen av en setning eller konteksten den brukes i. Kort sagt, XLIFF er bra!

Hvor skal vi lagre oversettelsesfilene våre?

Dette spørsmålet introduserer en Beste praksis. Sensio anbefaler å lagre filene våre i app/Ressurser/oversettelser.

Vanligvis pleide vi å lagre oversettelsene våre i hver av pakkene våre. Det var ikke en dårlig ting, men oversettelser betraktes generelt som globale deler av appene våre, akkurat som globale maler, det er derfor Sensio anbefaler at vi lagrer dem i app.

Hvordan oversette våre applikasjoner?

Bruk alltid nøkler til å oversette innholdet ditt.
På dette Beste, Jeg vil ikke si min mening siden jeg har liten mulighet til å oversette søknader. Sensio anbefaler at for å oversette et ord som "Brukernavn", bør du bruke en nøkkel som f.eks label.brukernavn.

Et eksempel er gitt på side 35.

Sikkerhet

Kapittel 9 i boken, omhandler en sentral del av Symfony; sikkerhet !

Symfony ble designet for å enkelt konfigurere og autentisere brukere som ønsker å koble til applikasjonene våre. Denne delen er veldig kompleks og full av detaljer, så det er en grov oversikt. Du finner mer dokumentasjon på den dedikerte siden.

Deklarer brannmurene dine

Konfigurasjonsalternativene skal legges inn i filen sikkerhet.yml som er i app/konfig.

Med mindre du har to forskjellige tilkoblinger til applikasjonen din (system og brukere), anbefaler vi å bruke bare én inngangsbrannmur med det anonyme alternativet aktivert.
Wow wow wow! Vent, jeg ankommer Symfony, jeg skjønte ingenting!

Hva er en brannmur?

Du kan finne en artikkel laget i Wanadev, om hvordan du deklarerer og setter opp innebygd autentisering på Symfony. I denne artikkelen er det detaljert hva som er en brannmur.

En enkelt brannmur? Hvorfor en ?

Hvis du nettopp har lest artikkelen som er koblet til ovenfor, har du kanskje lagt merke til at flere brannmurer har blitt deklarert.

I den gitte artikkelen var de tre navnene dev, main et Logg inn. Til tross for dette respekteres den gitte regelen, bare en brannmur kan betraktes som en gateway.

  • dev : denne brannmuren tillater debug-bar å vise.
  • main : denne brannmuren er vår INNGANGSPUNKT. Anonyme brukere vil kunne logge på som for å respektere regelen. Alle ruter som begynner med / vil bruke denne oppføringen.
  • Logg inn : det er en brannmur. Dette vil være inngangsporten vår i et enkelt tilfelle: hvis vi ønsker å koble til. Dette er viktig for å ha tilgang til et påloggingsskjema.
    Regelen respekteres derfor.

Definer en koding

Koding av passord er en nøkkelavgjørelse. Det finnes flere algoritmer, som f.eks sha (sha1, sha256, sha512, md5...).

Når du deklarerer en koding (se hvordan du deklarerer en koding), kan tre parametere angis.

  • Krypteringsalgoritmen (standard: sha512);
  • Antall iterasjoner (som standard: 5000);
  • Kodingen er base64 for det kodede passordet (standard: sant).
    Til tross for disse standardverdiene, som jeg inviterer deg til å endre for å endre dem for applikasjonene dine. Sensio anbefaler også å bruke algoritmen bcrypt.

    Bruk bcrypt-koding for å kryptere brukerpassord.
    Sensio forklarer hvordan du bruker bcrypt. Dette inkluderer en salting verdi. Dette begrenser angrep og er mer motstandsdyktig mot angrep av brute force. Du finner flere detaljer i Wikipedia-artikkelen ovenfor.

Angi tillatelser

Under en tilkobling oppdager Symfony hvilken brannmur som skal brukes. Deretter, og selv før du får tilgang til kontrolleren, utføres en tilgangskontroll. De er definert i filen sikkerhet.yml,

Sensio anbefaler:

  1. beskytte våre "edge URL-mønstre", forstå våre globale mønstre (eksempel: /admin);
  2. Bruk merknader @Sikkerhet så mye som mulig ;
  3. Sjekk rettighetene for en bruker via tjenesten sikkerhetskontekst (siden Symfony 2.6 har tjenesten utviklet seg, se her);
  4. Definer velgere for å enkelt administrere trafikksikkerheten;
  5. Bruke ACL å administrere objekt- og brukerrettigheter.

Bruk @Security-kommentarer

Sensio anbefaler å bruke @Security-kommentaren.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
bruke SensioXNUMX bunkFrameworkExtraBundleKonfigurasjonRute;
bruke SensioXNUMX bunkFrameworkExtraBundleKonfigurasjonSikkerhet;
// ...
/ **
* Viser et skjema for å opprette en ny Post-enhet.
* @Vei("/new", name="admin_post_new")
* @Sikkerhet("has_role('ROLE_ADMIN')")
*/
offentlig funksjon nyAksjon()
{
// ...
}

Bruk uttrykk for å gjøre restriksjoner mer komplekse

Sensio forklarer oss at denne merknaden også gjør det mulig å generere mer komplekse forhold, for eksempel en sammenligning av to attributter mellom to objekter. Denne merknaden kan kreve bruk av ParamConverter.

Du finner mer informasjon i dokumentet:

  • Generer uttrykk
  • Konverter attributter til objekter

Adgangssikkerhet i Twig

Hvis du ønsker å sammenligne den tilkoblede brukeren med brukeren av et objekt, kan du få tilgang fra Twig the bruker I prosess.

1
2
3
{% if app.bruker … %}
...
{% endif %}

Administrer sikkerheten din enkelt

Å administrere sikkerhet er ofte en sensitiv del, og organisering av koden vår er en viktig del av å sikre applikasjonen vår. Bruken av Velgere anbefales på det sterkeste. Andre måter å organisere koden på kan vurderes. For eksempel kan vi overføre en avgjørelse til en metode for vår enhet.

Du kan se Sensio-eksemplet på side 40.

Denne delen er svært lite detaljert sammenlignet med mulighetene som Symfony tilbyr. Jeg anbefaler deg å lese litt mer dokumentasjon om denne delen hvis du står overfor en sikkerhetsoppgave.

Nettressurser

Eiendeler lar oss administrere ressurser som Javascript, CSS, fos-fonter, bilder ... slik at de er tilgjengelige fra sidene dine.

Eiendelene dine må lagres i web/mappen
På denne måten kan du laste inn ressursene dine i malene dine slik:

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

Behold den offentlige nettmappen og alt som er lagret i den.

Bruk Assetic

Assetic har flere interesser, for eksempel filkompilering. For eksempel, Less, Sass, TypeScript-filer ... Av denne grunn, mappen web kan ikke inneholde filer som filer .mindre.

Bruk Assetic til å kompilere, kombinere og minimere eiendelene dine med mindre du bruker GruntJS.

Lær mer om Assetic

Assetic er et komplett verktøy til tross for noen ulemper. Du kan finne dokumentasjon om denne modulen ved å bruke lenkene nedenfor:

  • Bruk Assetic
  • Reduser CSS og JS
  • Komprimer bilder
  • Se den offisielle dokumentasjonen

Sett opp tester

Testing er anerkjent av de fleste utviklere som viktig. Likevel implementerer bare et mindretall dem.

Vi får se hvordan Sensio råder oss til å gjennomføre testene våre.

Utfør enhetstester

Enhetstester brukes til å utføre funksjonstester som igjen vil teste logikken til applikasjonen din. Symfony har ikke bestemt noen spesielle verktøy for å teste testene dine. Verktøyene PHPUnit et PhpSpec er sitert.

Utføre funksjonstester

Det er viktig å lage gode scenarier for funksjonstestene dine, og likevel får utviklere raskt problemer med å implementere dem.

Definer en funksjonstest for å teste om siden din har lastet inn riktig.

Forsøk å bruke hardkodede URL-er i stedet for å generere dem gjennom generatoren.

Test JavaScript-funksjonalitet

Mange verktøy finnes som mink (et PHPUnit-bibliotek) og CasperJS.

Generer datasett

Dette er ofte et problem for utviklere som genererer datasett.

Sensio anbefaler bruk av biblioteker mer et Alice.

konklusjonen

Denne artikkelen er hentet fra Beste praksis for Symfony. Selv om den forblir enkel, har denne artikkelen som mål å dissekere de 50 sidene med råd for å veilede nye Symfony-utviklere.

★ ★ ★ ★ ★