Name: Tremplin Numérique
Price range: $$$

För några dagar sedan presenterade Fabien Potencier via Sensio en e-bok som sammanför bästa praxis och rekommendationer för att utveckla ett Symfony-projekt. Sammanställt från rekommendationer publicerade av communityn, syftet med detta dokument är att ge en uppsättning råd relaterade till philoSophia från Symfony. Jag ska försöka att kort sammanfatta de 31 tipsen som beskrivs på engelska i det här inlägget.

Sommaire

Beskrivning

Detta dokument börjar med några råd och några meningar som är avsedda att inspirera oss med dokumentet.

"Det här dokumentet är inte en handledning"

Detta dokument skrevs med avsikten att läsas av alla Symfony-utvecklare. Både experter och neofyter.

"Refaktorera inte dina appar"

Från början av dokumentet förklaras det specifikt att vi efter denna läsning inte bör uppdatera och refaktorisera våra applikationer för att det ska passa perfekt med Sensios flera rekommendationer. Vi kan därför omedelbart göra kopplingen till de första idéerna som utvecklats i dokumentet: dessa goda rutiner bör göra det möjligt för oss att förenkla våra liv, samt förenkla kodgranskning. Till stöd för mina anmärkningar har tre skäl framförts:

Dina befintliga applikationer är inte fel, de följer bara en annan uppsättning riktlinjer;

En fullständig kodbasrefaktorering är benägen att introducera fel i dina applikationer;

Mängden arbete som spenderas på detta skulle kunna ägnas bättre åt att förbättra dina tester eller lägga till funktioner som ger verkligt värde för slutanvändarna.

Skapa ett projekt

I kapitel 2 som handlar om hur man deklarerar och skapar ett Symfony-projekt, ges en första "Bästa praxis":

_Använd alltid Composer. _Composer introducerade grunderna i modern PHP genom dess beroendeupplösning. Tack vare honom registrerade beroenden i filen kompositör.json kommer att lösas och repatrieras i ditt projekt så att det är användbart. Dessutom kan enkla uppdateringar göras.

På så sätt kan du respektera den strukturella organisationen av ett Symfony-projekt. (se sidan 8).

Exempel:

app/cache kommer att lagra cachen;
app/loggar lagra stockar;
app/resurser kommer att lagra mallarna såväl som de globala översättningarna för din applikation;
src / lagra dina applikationspaket;
Säljare/ lagra ditt projekts beroenden;
webb/ kommer att lagra tillgångarna (css, js, bilder, etc.) såväl som frontfilen (app.php) så att du kan omdirigera dina förfrågningar till dina kontroller.
Som ett resultat, en ny rekommendation om paket. Utan att göra min egen analys som skulle kunna ifrågasätta philosophie från Symfony (vilket jag inte vill ha), här är rekommendationen:

Skapa ett enda AppBundle-paket för en applikation. Detta beror på hur Symfony designades. Varje paket måste vara _fristående. _De ska därför kunna leva självständigt och självständigt.

Jag låter dig meditera över denna rekommendation...

konfiguration

Det tredje kapitlet ger oss råd om hur du konfigurerar dess tillämpning. Vissa konfigurationsobjekt kan variera från ett utvecklingssystem till ett produktionssystem.

Som rekommendationen anger måste du därför definiera konfigurationen för din infrastruktur i filen app/config/parameters.yml.

Omvänt kommer konfigurationen som är specifik för ditt projekt, som kommer att vara statisk, att deklareras i app/config/config.yml.

Dessutom filen parameters.yml bör inte versioneras. Det här är filen parameters.yml.dist vem borde vara. Det är den här filen som ger dig grundläggande alternativ för att konfigurera din applikation. (rekommendation sida 12).

Som ett resultat, filen _app/config/config.yml _själv fungerar som en rekommendation.

Ställ in konfigurationen relaterad till din applikation i app/config/config.yml
Efter denna rekommendation är det dock tillrådligt att skapa en fil config.yml, config_dev.yml och en fil config_prod.yml. Dessa filer är avsedda att lagra konstanterna som är specifika för utvecklingsmiljön och produktionsmiljön.
Vi måste betrakta ett värde som konstant när dess värde ändras väldigt lite.

Beroendeinjektion

Här är vi ! I det tredje kapitlet beskrivs en rekommendation om användningen av beroenden. Jag råder dig att läsa den här rekommendationen om min förklaring verkar vag för dig.

Denna rekommendation handlar om att injicera tjänster i tjänster. Sensio rekommenderar att deklareras i en fil src/AppBundle/Resources/config/services.yml.

Jag inbjuder dig också att läsa min artikel om beroendeinjektion och hur man begränsar användningen av superservicebehållaren.

Deklarera intern logik

Kapitel 4 handlar om hur du organiserar din ansökan. Beroende på dina behov kommer organisationen att skilja sig åt. För globala och icke-affärsfunktioner rekommenderar Sensio att du placerar dem i en mapp utils eller helt enkelt ta ut dem ur paketet och lägg det i en separat mapp. Efter detta rekommenderas det starkt att du deklarerar din klass som en tjänst. En ny rekommendation ges för att hjälpa oss att deklarera dem.

Namnet på din tjänst bör vara så kort som möjligt, helst ett enda ord.

Att välja filformat

Eftersom jag är särskilt fäst vid Yaml-formatet inom Symfony, föreställer jag mig att denna punkt kommer att skapa osämja. Sensio rekommenderar kompromisslöst att använda Yaml-formatet i applikationer. De utvecklade paketen delas mellan två format: XML och Yaml.

Sensio bestämde sig för att rekommendera det senare helt enkelt för att det är mer " användarvänligt ". Att använda ett annat format skulle inte ändra hur din applikation fungerar.

Definiera inte en variabel för deklarationen av dina tjänster

Detta är en praxis som du kommer att se mycket i vissa paket och ändå varnar Sensio dig. Här är exemplet som ges i kokbok :

#app/config/services.yml
# tjänst definition med klassnamnutrymme som parameter
parametrar:
slugger.class: AppBundleUtilsSlugger
tjänster:
 slugger:
 klass:
"%slugger.class%"

Här är exemplet på en värdelös kod. Att förklara klassen att använda för en tjänst är ett misstag, eftersom denna variabel möjligen kan användas någon annanstans i koden. Dessutom, och detta är skälet som Sensio angett, tynger det skapandet av tjänsten.

Valet av ORM

Sensio rekommenderar användningen av Doctrin ORM inom Symfony. Som en Doctrin-användare är dess integration i Symfony mycket avancerad. Detta resulterar i en rekommendation som återlanserar den logiska organisationen av våra projekt. Enhetsdeklarationen måste hålla logiken i ett paket. Se exempel på sidan 18.

Deklaration av kartläggningen

Deklarationen av Doktrinkartläggningen bör helst genomföras tack vare de anteckningar som rekommenderas inom ramen för Doktrin men även för andra tillämpningar.

Använd anteckningar för att deklarera entitetsmappning.
Ett exempel finns på sidan 19.

Installation av fixturer

Sensio råder utan att lägga fram det, att sätta upp fixturer. För de oinitierade är dessa datauppsättningar som kommer att användas som standard för att starta programmet innan det ens sätts i produktion.

Kodningsstandarder (slutet av kapitel 4)

Det här är en del som Sensio konstigt nog nästan har förmörkat. Säger jag konstigt eftersom det är en viktig del för mig.

Symfony är kodad enligt PSR1- och PSR2-standarderna. Dessa standarder måste främjas inom gemenskapen av Symfony-utvecklare men även med PHP-utvecklare. Symfony har postat en artikel för att samla in och lyfta fram " Kodningsstandarder ". Ledaren för Sensio, Fabien Potencier har också lagt ett verktyg på GitHub för att utföra kontroller av efterlevnad av standarder.

Kontroller

När det kommer till kontroller, Symfonys philosophie "tunna kontroller och feta modeller". Det betyder att kontroller bör förbli lätta. Varje metod (åtgärd) som kommer att nås via en rutt representerar en åtgärd. Koden för var och en av dessa metoder måste vara "lätt" och anropa och samordna åtgärder. Dessa aktier måste finnas i tjänster.

Denna modell presenterar en styrenhet som använder applikationskoder/delar.

En kontrollant måste följa några regler

En regulator måste ha maximalt 5 variabler.
En kontrollant har maximalt 10 åtgärder.
Varje åtgärd måste innehålla högst 20 rader.
- En metod kan innehålla mer än 20 rader, förutsatt att koden som används inte kan faktoriseras.
  
  En styrenhet bör ärva Sensios FrameworkBundle-basstyrenhet och använda anteckningar för att hantera rutter, cachelagring och säkerhet.
  
  Användning av anteckningar rekommenderas, men användningen av XML, YAML eller PHP är också giltig. Applikationen bör endast använda ett enda format.

Använd inte @Mallen

Detta är en rekommendation för de mindre oväntade och ändå är förklaringen särskilt kraftfull.

Använd inte @Template()-kommentaren för att konfigurera mallen som används av styrenheten
Förklaringen är enkel, @Template använder en TemplateListener som anropas när händelsen kernel.view kastas.
Under framtagandet av detta dokument genomfördes ett test. Användningen av @Mall tar 26 ms innan genereringen startas medan för samma sida som skulle ha genererats med " $this->render(...) », väntetiden på 5 millisekunder.

Använd ParamConverter-anteckning

Användningen av denna anteckning gör det möjligt att automatisera hydratiseringen av en entitet.

Att använda ParamConverter-tricket är bra när det är enkelt och bekvämt.

Mallar

Kapitel 6 beskriver mallgenereringen. Det är utan _krångel _vad dokumentet ger oss i kölvattnet av flera rekommendationer.

Använd Twig-mallmotorn
Sensio rekommenderar Twig av många anledningar. Förutom att vara en motor används ofta av PHP-gemenskapen, både av PHP-utvecklare från början, endast av Symfony-utvecklare och andra ramverk. Enkelhet betonas och marknadsföringen av deras produkt är tydligt synlig. Slutligen garanterar Sensio stöd för Symfony upp till dess version 3. Du kan också hitta de första övergångarna att göra för att förbereda din kod för att migrera till version 3.
Lagra ansökningsmallar i app/Resurser/vyer.
Som standard har utvecklare blivit vana vid att lagra sina mallar i mappen Resurser av varje bunt. Detta är inte en dålig sak men Fabien Potencier rekommenderar att du lagrar de globala mallarna för din applikation i mappen som nämns ovan.
Definiera dina Twig-förlängningar i AppBundle/Twig och konfigurera tjänsterna i app/config/services.yml.
Kvistförlängningar lider av dålig sikt. Dessa tillägg, hur användbara de än är, används ibland för systematiskt. Sensio presenterar denna del som jag tycker är viktig, som ett sätt att injicera affärskod i sina mallar. Jag rekommenderar dig att läsa hur du deklarerar en Twig-förlängning.

Blanketter

Kapitel 7 ger oss instruktioner om hur du använder formulär.

Definiera dina formulär i PHP-klasser.
Symfony ger möjligheten att generera PHP-klasser som tillåter automatiserad generering av formulär för givna enheter. DE Blanketter som de kallas, erbjuder fullständig integration. Ändringen av enheter assisteras. Dessutom gör användningen av Forms det möjligt att deportera hanteringen av blanketter från mallar.
Deklarera inte en knapp för att skicka dess formulär.
Detta är en överraskande poäng, eftersom den här funktionen introducerades i Symfony 2.5. När dessa rader skrivs är Symfony 2.6 på väg att accepteras och har därför ännu inte släppts officiellt. Vi kan därför ställa några frågor om användbarheten av denna funktionalitet, den bör inte användas!Lägg till knappar i mallar snarare än i Formulär, varför?
I sin förklaring förklarar Sensio-teamet att även om denna funktion finns kvar "användarvänlig" och att det förenklar implementeringen av formulär förblir vissa funktioner begränsade.
Exempel, om du lägger till en knapp av typen skicka med etiketten "Skapa" kan detta formulär inte återanvändas för en redigeringssida. Du kommer då att behöva deklarera din blankett som en tjänst för att utföra ett arv, vilket inte rekommenderas lite längre ner.
Använd inte Twig-funktioner form() och _formStart().
En del dedikerad till rendering av mallar har satts upp. Hon lär oss att användningen av Twig fungerar form() och _ form_start()_ är utfasad. Återigen är detta ett fel för mig eftersom dessa funktioner nyligen har varit tillgängliga.
I Symfony finns det flera sätt att rendera ett formulär. Av de olika sätten att rendera är det bästa sättet ett som erbjuder maximal flexibilitet.
Att använda Twig-funktionerna ovan ger liten fördel. Sensio talar om ökad läsbarhet vid användning av inbyggda HTML-taggar. Trots detta argument representerar detta en liten fördel... Mycket liten!

Deklarera dina formulär som tjänster

Formulär är PHP-klasser vilket innebär att de kan deklareras som en tjänst. Du kommer att kunna se denna metod i paketen av FriendsOfSymfony. Denna metod rekommenderas inte av Sensio förutom i vissa fall som jag citerar nedan:

Om du vill återanvända befintliga formulär. Att sätta upp arvet mellan två former gör det möjligt att begränsa omskrivningen av alla attribut.
Om vi vill bädda in samlingar av enheter.
Användning av formulär som tjänster i fallet med ett lägg till eller redigera formulär rekommenderas inte eftersom användningen av en tjänst laddar @behållare. Dessutom kommer det att vara svårt att förstå att denna tjänst används av en kontrollant.

Fäst (pärm) dess former

Sensio började nyligen en konstant migrering av Symfony2-kod till framtida Symfony3-kod. Bland listan över ändringar som kan göras (du hittar dem alla i UPGRADE-3.md), finns den nya lösningen för bindemedel begäran skickad av ett formulär med formen som skapades. Den nya metoden beskrivs i detalj på sidan 21 i Best Practices.

Rösta utdraget som presenteras:

allmän fungera newAction(Begär $request)
{
// bygg din form
$form->handleRequest($request);
if ($form->isSubmitted() && $form->isValid()) {
$em = $ detta->behållare->få("doctrine.orm.default_entity_manager");
$em->persist($post);
$em->flush();
avkastning $ detta->redirect($ detta->generateUrl("admin_post_show"), array("id" => $post->getId()));
}
}

internationalisering

Syftet med internationaliseringsmodulen är att översätta innehållet från ett språk till ett annat, beroende på region eller användarens språk. Mer än rekommendationsdata har detta kapitel skrivits mer för att visa möjligheterna på denna del som alltid förblir känslig.

I kapitel 8 beskriver redaktörerna hur man aktiverar översättning.

hur är det med formatet

Symfony erbjuder en mängd översättningsformat:

PHP
Qt
.po
.mo
JSON
CSV
DETTA
och många andra

Använd XLIFF-formatet för dina översättningsfiler.
Detta citat är uppenbarligen en Sensio-rekommendation. Ja men varför ? Ett kort och exakt svar ges till oss.
Bland alla format som stöds är det bara XLIFF-formatet och gettext-formatet som stöds av professionella översättningsverktyg. Eftersom XLIFF är baserat på XML drar det nytta av innehållsvalidering.
Symfony 2.6 har en ny funktion som låter dig "kommentera" (lägga till anteckningar) i dina XLIFF-filer. Detta är en stor nyhet, eftersom genereringen av översättningsfiler kan orsaka problem för översättare att förstå innebörden av en mening eller sammanhanget där den används. Kort sagt, XLIFF är bra!

Var lagrar vi våra översättningsfiler?

Denna fråga introducerar en Bästa praxis. Sensio rekommenderar att du lagrar våra filer i app/Resurser/översättningar.

Vanligtvis brukade vi lagra våra översättningar i vart och ett av våra paket. Det var inte dåligt, men översättningar anses generellt vara globala delar av våra appar, precis som globala mallar, det är därför Sensio rekommenderar att vi lagrar dem i app.

Hur översätter man våra applikationer?

Använd alltid nycklar för att översätta ditt innehåll.
På detta Bäst, Jag kommer inte att ge min åsikt eftersom jag har små möjligheter att översätta ansökningar. Sensio rekommenderar att för att översätta ett ord som "Användarnamn" bör du använda en nyckel som t.ex label.username.

Ett exempel finns på sidan 35.

säkerhet

Kapitel 9 i boken, berör en central del av Symfony; säkerhet !

Symfony har utformats för att enkelt konfigurera och autentisera användare som vill ansluta till våra applikationer. Den här delen är mycket komplex och full av detaljer, så det är en grov översikt. Du kan hitta mer dokumentation på den dedikerade sidan.

Deklarera dina brandväggar

Konfigurationsalternativen ska anges i filen säkerhet.yml som är inne app/config.

Om du inte har två olika anslutningar till din applikation (system och användare), rekommenderar vi att du endast använder en brandvägg med det anonyma alternativet aktiverat.
Wow wow wow! Vänta, jag anländer till Symfony, jag förstod ingenting!

Vad är en brandvägg?

Du kan hitta en artikel gjord i Wanadev om hur man deklarerar och ställer in inbyggd autentisering på Symfony. I den här artikeln beskrivs vad som är en brandvägg.

En enda brandvägg? Varför en ?

Om du precis har läst artikeln som länkas till ovan kanske du har märkt att flera brandväggar har deklarerats.

I den givna artikeln var de tre namnen dev, huvudsakliga et logga in. Trots detta respekteras den givna regeln, endast en brandvägg kan betraktas som en gateway.

dev : denna brandvägg tillåter debug-bar att visa.
huvudsakliga : den här brandväggen är vår INKÖRSPORT. Anonyma användare kommer att kunna logga in som för att respektera regeln. Alla rutter som börjar med / kommer att använda denna post.
logga in : det är en brandvägg. Detta kommer att vara vår gateway i ett enda fall: om vi vill ansluta. Detta är viktigt för att ha tillgång till ett inloggningsformulär.
Regeln respekteras därför.

Definiera en kodning

Att koda lösenord är ett viktigt beslut. Det finns flera algoritmer, som t.ex sha (sha1, sha256, sha512, md5...).

När du deklarerar en kodning (se hur du deklarerar en kodning) kan tre parametrar anges.

Krypteringsalgoritmen (standard: sha512);
Antalet iterationer (som standard: 5000);
Kodningen är base64 för det kodade lösenordet (standard: true).
Trots dessa standardvärden, som jag uppmanar dig att ändra för att modifiera dem för dina applikationer. Sensio rekommenderar också att använda algoritmen bcrypt.

Använd bcrypt-kodning för att kryptera användarlösenord.
Sensio förklarar hur man använder bcrypt. Detta inkluderar en saltning värde. Detta begränsar attacker och är mer motståndskraftigt mot attacker av brute force-typ. Du kan hitta mer information i Wikipedia-artikeln ovan.

Ange behörigheter

Under en anslutning upptäcker Symfony vilken brandvägg som ska användas. Därefter, och även innan åtkomst till styrenheten, utförs en åtkomstkontroll. De definieras i filen säkerhet.yml,

Sensio rekommenderar:

skydda våra "edge URL-mönster", förstå våra globala mönster (exempel: /admin);
Använd anteckningar @Säkerhet så mycket som möjligt ;
Kontrollera rättigheterna för en användare via tjänsten säkerhet.kontext (sedan Symfony 2.6 har tjänsten utvecklats, se här);
Definiera väljare för att enkelt hantera trafiksäkerheten;
Använd ACL att hantera objekt och användarrättigheter.

Använd @Security-kommentarer

Sensio rekommenderar att du använder @Security-anteckningen.

användning SensioBuntFrameworkExtraBundlekonfigurationRutt;
användning SensioBuntFrameworkExtraBundlekonfigurationsäkerhet;
//…
/ **
* Visar ett formulär för att skapa en ny post-enhet.
* @Väg("/new", name="admin_post_new")
* @Säkerhet("has_role('ROLE_ADMIN')")
*/
allmän fungera newAction()
{
//…
}

Använd uttryck för att göra begränsningar mer komplexa

Sensio förklarar för oss att denna annotering också gör det möjligt att generera mer komplexa villkor, som en jämförelse av två attribut mellan två objekt. Denna anteckning kan kräva användning av ParamConverter.

Du kan hitta mer information i dokumentet:

Generera uttryck
Konvertera attribut till objekt

Åtkomstsäkerhet i Twig

Om du vill jämföra den anslutna användaren med användaren av ett objekt kan du komma åt från Twig the användare pågår.

1
2
3

{% if app.användare … %}
.
{% endif %}

Hantera din säkerhet enkelt

Att hantera säkerhet är ofta en känslig del, och att organisera vår kod är en viktig del för att framgångsrikt säkra vår applikation. Användningen av Väljarna rekommenderas starkt. Andra sätt att organisera din kod kan övervägas. Till exempel kan vi överföra ett beslut till en metod för vår enhet.

Du kan se Sensio-exemplet på sidan 40.

Den här delen är väldigt lite detaljerad jämfört med de möjligheter som Symfony erbjuder. Jag råder dig att läsa lite mer dokumentation om denna del om du står inför en säkerhetsuppgift.

webbtillgångar

Tillgångar tillåter oss att hantera resurser som Javascript, CSS, fos-teckensnitt, bilder... så att de är tillgängliga från dina sidor.

Dina tillgångar måste lagras i webben/mappen
Så här kan du ladda dina resurser i dina mallar så här:

1 2	<länk Rel="stilmall" href=« {{ asset(‘css/bootstrap.min.css’) }}« /> <skript src=« {{ asset(‘js/jquery.min.js’) }}« ></skript>

Behåll den offentliga webbmappen och allt som finns lagrat i den.

Använd Assetic

Assetic har flera intressen, till exempel filkompilering. Till exempel, Less, Sass, TypeScript-filer... Av denna anledning, mappen webb kan inte innehålla filer såsom filer .mindre.

Använd Assetic för att kompilera, kombinera och förminska dina tillgångar om du inte använder GruntJS.

Lär dig mer om Assetic

Assetic är ett komplett verktyg trots vissa nackdelar. Du kan hitta dokumentation om denna modul genom att använda länkarna nedan:

Använd Assetic
Förminska CSS och JS
Komprimera bilder
Se den officiella dokumentationen

Ställ in tester

Testning anses av de flesta utvecklare som väsentligt. Ändå implementerar bara en minoritet dem.

Vi får se hur Sensio råder oss att genomföra våra tester.

Utför enhetstester

Enhetstester används för att utföra funktionstester som i sin tur testar logiken i din applikation. Symfony har inte bestämt några särskilda verktyg för att testa dina tester. Verktygen PHPUnit et PhpSpec är citerade.

Utför funktionstester

Det är viktigt att skapa bra scenarier för dina funktionstester, och ändå stöter utvecklare snabbt på problem med att implementera dem.

Definiera ett funktionstest för att testa om din sida har laddats korrekt.

Försök att använda hårdkodade webbadresser istället för att generera dem via generatorn.

Testa JavaScript-funktionalitet

Många verktyg finns som Mink (ett PHPUnit-bibliotek) och CasperJS.

Generera datamängder

Detta är ofta ett problem för utvecklare som genererar datauppsättningar.

Sensio rekommenderar användning av bibliotek mer et Alice.

Slutsats

Denna artikel är hämtad från Bästa metoder för Symfony. Även om den förblir enkel, syftar den här artikeln till att dissekera de 50 sidorna med råd för att vägleda nya Symfony-utvecklare.