Symfonyn parhaat käytännöt (virallinen suositus)
Verkkotoimisto » Digitaalisia uutisia » Symfonyn parhaat käytännöt (virallinen suositus)

Symfonyn parhaat käytännöt (virallinen suositus)

Muutama päivä sitten Fabien Potencier Sension kautta julkisti e-kirjan, joka kokoaa yhteen parhaat käytännöt ja suositukset Symfony-projektin kehittämiseen. Yhteisön lähettämistä suosituksista koottu tämän asiakirjan tarkoitus on antaa neuvoja, jotka liittyvät puhelimeeniloSophia Symfonystä. Yritän tehdä lyhyen yhteenvedon tässä viestissä kuvatuista 31 vinkistä englanniksi.

esittely

Tämä asiakirja alkaa muutamalla neuvolla ja muutamalla lauseella, joiden tarkoituksena on inspiroida meitä asiakirjassa.

"Tämä asiakirja ei ole opetusohjelma"

Tämä asiakirja on kirjoitettu kaikkien Symfony-kehittäjien aikomuksena lukea se. Sekä asiantuntijoita että aloittelijoita.

"Älä muokkaa sovelluksiasi"

Asiakirjan alusta lähtien on erityisesti selitetty, että tämän lukemisen jälkeen meidän ei tule päivittää ja muuttaa sovelluksiamme, jotta se sopisi täydellisesti Sension useiden suositusten kanssa. Voimme siis välittömästi luoda linkin dokumentissa kehitettyihin ensimmäisiin ajatuksiin: näiden hyvien käytäntöjen avulla voimme yksinkertaistaa elämäämme sekä yksinkertaistaa koodin tarkistusta. Kommenttieni tueksi esitän kolme syytä:

  • Nykyiset sovelluksesi eivät ole vääriä, ne vain noudattavat muita ohjeita;
  • Täysi koodikannan uudelleenmuodostus on taipuvainen aiheuttamaan virheitä sovelluksiisi;
  • Tähän käytetyn työn määrä voitaisiin keskittyä paremmin testien parantamiseen tai ominaisuuksien lisäämiseen, jotka tarjoavat todellista arvoa loppukäyttäjille.

Luo projekti

Luvussa 2, joka käsittelee Symfony-projektin ilmoittamista ja luomista, annetaan ensimmäinen "Paras käytäntö":

_Käytä aina Composeria. _Composer esitteli nykyaikaisen PHP:n perusteet riippuvuusratkaisunsa kautta. Hänen ansiostaan ​​riippuvuudet rekisteröitiin tiedostoon composer.json ratkaistaan ​​ja palautetaan projektiisi, jotta se on käyttökelpoinen. Lisäksi voidaan tehdä helppoja päivityksiä.

Tällä tavalla voit kunnioittaa Symfony-projektin rakenteellista organisaatiota. (katso sivu 8).

esimerkkejä:

  • sovellus/välimuisti tallentaa välimuistin;
  • sovellus/lokit tallentaa lokit;
  • sovellus/resurssit tallentaa mallit sekä yleiset käännökset sovelluksellesi;
  • src / tallentaa sovelluspaketit;
  • myyjä / tallentaa projektisi riippuvuudet;
  • verkko / tallentaa resurssit (css, js, kuvat jne.) sekä etutiedoston (app.php), jonka avulla voit myöhemmin ohjata pyyntösi ohjaimillesi.
    Tämän seurauksena uusi suositus nipuista. Tekemättä omaa analyysiäni, joka voisi kyseenalaistaa philosophie Symfonystä (jota en halua), tässä on suositus:

Luo yksi AppBundle-paketti sovellukselle. Tämä johtuu tavasta, jolla Symfony on suunniteltu. Jokaisen paketin on oltava _stand-alone. _Siksi heidän pitäisi pystyä elämään itsenäisesti ja itsenäisesti.

Jätän sinun mietiskellä tätä suositusta…

Konfigurointi

Kolmas luku antaa meille neuvoja sen sovelluksen määrittämiseen. Jotkut kokoonpanokohteet voivat vaihdella kehitysjärjestelmästä tuotantojärjestelmään.

Kuten suositus osoittaa, sinun on siksi määritä infrastruktuuriasi liittyvät asetukset tiedostossa app/config/parameters.yml.

Sitä vastoin projektikohtaiset konfiguraatiot, jotka ovat staattisia, ilmoitetaan app/config/config.yml.

Lisäksi tiedosto parametrit.yml ei pidä versioida. Tämä on tiedosto parametrit.yml.dist kenen pitäisi olla. Tämä tiedosto antaa sinulle perusasetukset sovelluksesi määrittämiseen. (suositus sivu 12).

Tämän seurauksena tiedosto _app/config/config.yml _toimii itse suosituksena.

Aseta sovellukseesi liittyvät asetukset osoitteessa app/config/config.yml
Tämän suosituksen mukaisesti on kuitenkin suositeltavaa luoda tiedosto config.yml, config_dev.yml ja tiedosto config_prod.yml. Nämä tiedostot on tarkoitettu tallentamaan kehitysympäristölle ja tuotantoympäristölle ominaiset vakiot.
Arvoa on pidettävä vakiona, kun sen arvo muuttuu hyvin vähän.

Riippuvuusinjektio

Täällä me olemme ! Kolmannessa luvussa on suositus riippuvuuksien käytöstä. Suosittelen lukemaan tämän suosituksen, jos selitykseni tuntuu epämääräiseltä.

Tämä suositus koskee palveluiden lisäämistä palveluihin. Sensio suosittelee ilmoittamaan ne tiedostossa src/AppBundle/Resources/config/services.yml.

Pyydän sinua myös lukemaan artikkelini riippuvuusruiskeesta ja siitä, miten superpalvelusäiliön käyttöä rajoitetaan.

Ilmoita sisäinen logiikka

Luvussa 4 käsitellään hakemuksesi järjestämistä. Organisaatio vaihtelee tarpeidesi mukaan. Globaalit ja ei-liiketoiminnalliset toiminnot Sensio suosittelee sijoittamaan ne kansioon utils tai ota ne pois nipustasi ja laita se erilliseen kansioon. Tämän jälkeen on erittäin suositeltavaa ilmoittaa luokkasi palveluksi. Uusi suositus on annettu auttamaan meitä julistamaan ne.

Palvelusi nimen tulee olla mahdollisimman lyhyt, mieluiten yksi sana.

Tiedostomuodon valinta

Koska olen erityisen kiintynyt Yaml-muotoon Symfonyssa, uskon, että tämä kohta lisää erimielisyyksiä. Sensio suosittelee tinkimättömästi Yaml-muodon käyttöä sovelluksissa. Kehitetyt paketit jaetaan kahdessa muodossa: XML ja Yaml.

Sensio päätti suositella jälkimmäistä yksinkertaisesti siksi, että se on enemmän " helppokäyttöinen ". Muun muodon käyttäminen ei muuta sovelluksesi toimintaa.

Älä määritä muuttujaa palveluidesi ilmoitukselle

Tämä on käytäntö, jota näet paljon tietyissä nipuissa, mutta Sensio kuitenkin varoittaa sinua. Tässä on julkaisussa annettu esimerkki keittokirja :

1
2
3
4
5
6
7
8
#app/config/services.yml
#palvelu definition luokan nimiavaruuden parametrina
parametrit:
slugger.class: AppBundleUtilsSlugger
palvelut:
slugger:
luokka:
"%slugger.class%"

Tässä on esimerkki turhasta koodista. Luokan ilmoittaminen palvelulle käytettäväksi on virhe, koska tätä muuttujaa voidaan mahdollisesti käyttää muualla koodissa. Lisäksi, ja tämä on Sension perustelu, se painaa palvelun luomista.

ORM:n valinta

Sensio suosittelee Doctrine ORM:n käyttöä Symfonyssa. Doctrine-käyttäjänä sen integrointi Symfonyyn on erittäin edistynyt. Tämä johtaa suositukseen, joka käynnistää uudelleen projektiemme loogisen organisoinnin. Entiteettiilmoituksen on säilytettävä logiikka nipun sisällä. Katso esimerkki sivulta 18.

Selvitys kartoituksesta

Doctrine-kartoituksen julistus tulisi mieluiten tehdä käyttämällä huomautuksia, joita suositellaan Opin puitteissa, mutta myös muihin sovelluksiin.

Käytä huomautuksia määrittääksesi entiteettikartoituksen.
Esimerkki on sivulla 19.

Valaisimien asennus

Sensio neuvoo laittamatta kiinni kalusteisiin. Asiattomille nämä ovat tietojoukkoja, joita käytetään oletuksena sovelluksen käynnistämiseen ennen sen tuotantoa.

Koodausstandardit (luvun 4 loppu)

Tämä on osa, jonka Sensio melkein varjosti oudosti. Sanon oudosti, koska se on minulle tärkeä osa.

Symfony on koodattu PSR1- ja PSR2-standardien mukaisesti. Näitä standardeja on edistettävä Symfony-kehittäjien yhteisössä, mutta myös PHP-kehittäjien kanssa. Symfony on julkaissut artikkelin kerätäkseen ja korostaakseen " Koodausstandardit ". Sension johtaja Fabien Potencie on myös asettanut GitHubiin työkalun standardien noudattamisen tarkistamiseksi.

Ohjaimet

Mitä tulee ohjaimiin, Symfonyn philosophie "ohuet ohjaimet ja paksut mallit". Tämä tarkoittaa, että ohjaimien tulee pysyä kevyinä. Jokainen menetelmä (toiminto), johon päästään reitin kautta, edustaa toimintoa. Jokaisen menetelmän koodin on oltava "kevyt" ja kutsua ja koordinoida toimia. Näiden osakkeiden on oltava palveluissa.

Tämä malli esittää ohjaimen käyttävän sovelluskoodeja/osia.

Ohjaajan on noudatettava muutamia sääntöjä

  • Ohjaimessa saa olla enintään 5 muuttujaa.
  • Ohjaimella on enintään 10 toimintoa.
  • Jokainen toiminto saa sisältää enintään 20 riviä.
    • Menetelmä voi sisältää enemmän kuin 20 riviä, edellyttäen, että käytettyä koodia ei voida kertoa.

      Ohjaimen tulee periä Sension FrameworkBundle-perusohjain ja käyttää huomautuksia reittien, välimuistin ja suojauksen hallintaan.

      Annotaatioiden käyttö on suositeltavaa, mutta myös XML:n, YAML:n tai PHP:n käyttö kelpaa. Sovellus saa käyttää vain yhtä muotoa.

Älä käytä @Templatea

Tämä on suositus vähemmän odottamattomille, mutta selitys on kuitenkin erityisen voimakas.

Älä käytä @Template()-merkintää ohjaimen käyttämän mallin määrittämiseen
Selitys on yksinkertainen, @Template käyttää TemplateListeneria, jota kutsutaan tapahtuman yhteydessä kernel.view heitetään.
Tätä asiakirjaa laadittaessa suoritettiin testi. @Template:n käyttö kestää 26 ms ennen sukupolven käynnistämistä, kun taas tälle samalle sivulle, joka olisi luotu käyttämällä " $this->render(…) », odotusaika 5 millisekuntia.

Käytä ParamConverter-merkintää

Tämän merkinnän käyttö mahdollistaa kokonaisuuden hydratoinnin automatisoinnin.

ParamConverter-tempun käyttäminen on hyvä, kun se on yksinkertaista ja kätevää.

Mallit

Luvussa 6 kerrotaan mallin luomisesta. Asiakirja antaa meille useiden suositusten jälkeen ilman _hälyä _.

  • Käytä Twig-mallimoottoria
    Sensio suosittelee Twigia monista syistä. Sen lisäksi, että on a moottori PHP-yhteisön laajalti käytössä, molemmat PHP-kehittäjät tyhjästä, vain Symfonyn kehittäjät ja muut puitteet. Yksinkertaisuus korostuu ja heidän tuotteensa promootio näkyy selvästi. Lopuksi Sensio takaa tuen Symfonylle sen versioon 3 asti. Löydät myös ensimmäiset siirtymät, jotka on tehtävä koodin valmistelemiseksi siirtymään versioon 3.
  • Tallenna sovellusmallit sisään sovellus/resurssit/näkymät.
    Oletuksena kehittäjät ovat tottuneet tallentamaan mallinsa kansioon Esittelymateriaalit jokaisesta nipusta. Tämä ei ole huono asia, mutta Fabien Potencie suosittelee tallentamaan sovelluksesi globaalit mallit yllä mainittuun kansioon.
  • Määritä Twig-laajennukset AppBundle/Twig ja määritä palvelut sisään app/config/services.yml.
    Oksun pidennykset kärsivät huonosta näkyvyydestä. Näitä laajennuksia, vaikka ne olivat erittäin hyödyllisiä, käytetään joskus liian järjestelmällisesti. Sensio esittelee tämän mielestäni olennaisen osan tapana lisätä liiketoimintakoodia malleihinsa. Suosittelen, että luet Twig-laajennuksen ilmoittamisen.

Lomakkeet

Luvussa 7 on ohjeita lomakkeiden käyttöön.

  • Määritä lomakkeesi PHP-luokissa.
    Symfony antaa mahdollisuuden luoda PHP-luokkia, jotka mahdollistavat lomakkeiden automaattisen luomisen tietyille entiteeteille. THE Lomakkeet kuten niitä kutsutaan, tarjoaa täydellisen integraation. Kokonaisuuksien muokkaamista avustetaan. Lisäksi Forms mahdollistaa lomakkeiden hallinnan poistamisen malleista.
  • Älä määritä painiketta lomakkeen lähettämiseksi.
    Tämä on yllättävä kohta, koska tämä ominaisuus esiteltiin Symfony 2.5:ssä. Näitä rivejä kirjoitettaessa Symfony 2.6 on hyväksymisvaiheessa, eikä sitä siksi ole vielä julkaistu virallisesti. Siksi voimme esittää kysymyksiä tämän toiminnon hyödyllisyydestä, sitä ei pidä käyttää!Miksi lisätä painikkeita malleihin lomakkeiden sijaan?
    Selityksessään Sensio-tiimi selittää, että vaikka tämä ominaisuus säilyy "käyttäjäystävällinen" ja koska se yksinkertaistaa lomakkeiden toteuttamista, tietyt toiminnot ovat edelleen rajoitettuja.
    Jos esimerkiksi lisäät tyypin painikkeen antaa "Luo"-tunnisteella tätä lomaketta ei voi käyttää uudelleen muokkaussivulle. Tämän jälkeen sinun on ilmoitettava lomakkeesi palveluksi perinnön suorittamiseksi, mikä ei ole suositeltavaa hieman alempana.
  • Älä käytä Twig-toimintoja muoto () ja _lomakealkaa().
    Mallien hahmontamiseen omistettu osa on perustettu. Hän opettaa meille Twig-toimintojen käytön muoto () ja _ form_start()_ on vanhentunut. Jälleen kerran tämä on virhe minulle, koska nämä toiminnot ovat olleet käytettävissä vasta äskettäin.
    Symfonyssa on useita tapoja hahmontaa lomake. Erilaisista renderöintitavoista paras on tapa, joka tarjoaa maksimaalisen joustavuuden.
    Yllä lueteltujen Twig-toimintojen käyttämisestä ei ole juurikaan hyötyä. Sensio puhuu parantuneesta luettavuudesta käytettäessä natiivi HTML-tageja. Tästä väitteestä huolimatta tämä on pieni etu… Erittäin pieni!

Ilmoita lomakkeesi palveluiksi

Lomakkeet ovat PHP-luokkia, mikä tarkoittaa, että ne voidaan ilmoittaa palveluiksi. Voit nähdä tämän menetelmän nipuissa Symfonyn ystävät. Sensio ei suosittele tätä menetelmää paitsi tietyissä tapauksissa, joita lainaan alla:

  • Jos haluat käyttää olemassa olevia lomakkeita uudelleen. Kahden lomakkeen välisen perinnön asettaminen mahdollistaa kaikkien määritteiden uudelleenkirjoittamisen rajoittamisen.
  • Jos haluamme upottaa kokonaisuuksia.
    Lomakkeiden käyttöä palveluina lisä- tai muokkauslomakkeen tapauksessa ei suositella, koska palvelun käyttö lataa @kontti. Lisäksi on vaikea ymmärtää, että ohjain käyttää tätä palvelua.

Kiinnitä (sido) sen lomakkeet

Äskettäin Sensio aloitti jatkuvan Symfony2-koodin siirron tulevaan Symfony3-koodiin. Tehtävissä olevien muutosten luettelossa (löydät ne kaikki UPGRADE-3.md:stä) on uusi ratkaisu sideaine pyyntö lähetetään lomakkeella muoto joka luotiin. Uusi menetelmä on kuvattu yksityiskohtaisesti sivulla 21 Esimerkkikäytäntöjä.

Äänitä esitetty ote:

1
2
3
4
5
6
7
8
9
10
11
12
13
julkinen toiminto uusi toiminta(Pyyntö $pyyntö)
{
// rakentaa lomake
$lomake->handleRequest($pyyntö);
if ($form->isSubmitted() && $form->isValid()) {
$em = $ tätä->container->get("doctrine.orm.default_entity_manager");
$em->persist($post);
$em->flush();
palata $ tätä->uudelleenohjaus($ tätä->generateUrl("admin_post_show"), ryhmä("ID" => $post->getId()));
}
}

Kansainvälistyminen

Kansainvälistymismoduulin tarkoituksena on kääntää sisältö kielestä toiselle riippuen alueesta tai käyttäjän kielestä. Tämä luku on kirjoitettu enemmän kuin suositustietoja, vaan enemmänkin osoittamaan tämän osan mahdollisuudet, joka on aina arkaluonteinen.

Luvussa 8 editorit kertovat kuinka aktivoida käännös.

entä muoto

Symfony tarjoaa useita käännösmuotoja:

  • PHP
  • Qt
  • .po
  • .mo
  • JSON
  • CSV
  • ini
  • ja monet muut

    Käytä käännöstiedostoissasi XLIFF-muotoa.
    Tämä lainaus on ilmeisesti Sension suositus. Kyllä, mutta miksi ? Meille annetaan lyhyt ja täsmällinen vastaus.
    Kaikista tuetuista muodoista vain XLIFF-muotoa ja gettext-muotoa tukevat ammattimaiset käännöstyökalut. Koska XLIFF perustuu XML:ään, se hyötyy sisällön validoinnista.
    Symfony 2.6 tuo uuden ominaisuuden, jonka avulla voit "kommentoida" (lisätä muistiinpanoja) XLIFF-tiedostoihisi. Tämä on suuri uutuus, koska käännöstiedostojen luominen voi aiheuttaa kääntäjille ongelmia ymmärtää lauseen merkitystä tai kontekstia, jossa sitä käytetään. Lyhyesti sanottuna XLIFF on hyvä!

Missä käännöstiedostomme säilytetään?

Tämä kysymys esittelee a Paras harjoitus. Sensio suosittelee tiedostojen tallentamista sovellus/resurssit/käännökset.

Yleensä meillä oli tapana tallentaa käännöksemme jokaiseen nippuun. Se ei ollut huono asia, mutta käännöksiä pidetään yleisesti sovelluksiemme globaaleina osina, aivan kuten globaaleja malleja, minkä vuoksi Sensio suosittelee, että tallennamme ne sovelluksen.

Kuinka kääntää sovelluksemme?

Käytä aina näppäimiä sisällön kääntämiseen.
Tästä Parhaat, en anna mielipidettäni, koska minulla on vähän mahdollisuuksia kääntää sovelluksia. Sensio neuvoo, että kääntääksesi sanan, kuten "Käyttäjänimi", sinun tulee käyttää avainta, kuten etiketti.käyttäjänimi.

Esimerkki on sivulla 35.

Turvallisuus

Kirjan luku 9 koskee Symfonyn keskeistä osaa; turvallisuus !

Symfony on suunniteltu helpottamaan käyttäjien konfigurointia ja todentamista, jotka haluavat muodostaa yhteyden sovelluksiimme. Tämä osa on hyvin monimutkainen ja täynnä yksityiskohtia, joten se on karkea ääriviiva. Löydät lisää asiakirjoja omalta sivulta.

Ilmoita palomuurisi

Määritysvaihtoehdot tulee syöttää tiedostoon security.yml mikä on app/config.

Ellei sinulla ole kahta eri yhteyttä sovellukseesi (järjestelmä ja käyttäjät), suosittelemme käyttämään vain yhtä sisääntulopalomuuria anonyymi-vaihtoehdon ollessa aktivoituna.
Vau vau vau! Odota, saavun Symfonyyn, en ymmärtänyt mitään!

Mikä on palomuuri?

Löydät Wanadevissa tehdyn artikkelin alkuperäisen todennuksen ilmoittamisesta ja määrittämisestä Symfonyssa. Tässä artikkelissa kerrotaan yksityiskohtaisesti, mikä on palomuuri.

Yksi palomuuri? Miksi a?

Jos olet juuri lukenut yllä linkitetyn artikkelin, olet saattanut huomata, että useita palomuureja on ilmoitettu.

Annetussa artikkelissa kolme nimeä olivat dev, tärkein et Kirjaudu sisään. Tästä huolimatta annettua sääntöä noudatetaan, vain palomuuria voidaan pitää yhdyskäytävänä.

  • dev : tämä palomuuri sallii debug-palkki näyttää.
  • tärkein : tämä palomuuri on meidän SISÄÄNTULOPISTE. Anonyymit käyttäjät voivat kirjautua sisään ikään kuin noudattavat sääntöä. Kaikki / alkavat reitit käyttävät tätä merkintää.
  • Kirjaudu sisään : se on palomuuri. Tämä on yhdyskäytävämme yhdessä tapauksessa: jos haluamme muodostaa yhteyden. Tämä on välttämätöntä kirjautumislomakkeen käyttämiseksi.
    Sääntöä siis kunnioitetaan.

Määritä koodaus

Salasanojen koodaus on keskeinen päätös. Algoritmeja on useita, esim sha (sha1, sha256, sha512, md5...).

Koodausta määritettäessä (katso koodauksen ilmoittaminen) voidaan antaa kolme parametria.

  • Salausalgoritmi (oletus: sha512);
  • Iteraatioiden määrä (oletuksena: 5000);
  • Koodaus on koodatun salasanan base64 (oletus: tosi).
    Huolimatta näistä oletusarvoista, joita kehotan sinua muokkaamaan sovelluksillesi sopivaksi. Sensio suosittelee myös algoritmin käyttöä bcrypt.

    Käytä bcrypt-koodausta käyttäjien salasanojen salaamiseen.
    Sensio selittää kuinka bcryptia käytetään. Tämä sisältää a suolaus arvo. Tämä rajoittaa hyökkäyksiä ja kestää paremmin raa'an voiman tyyppisiä hyökkäyksiä. Löydät lisätietoja yllä olevasta Wikipedia-artikkelista.

Aseta käyttöoikeudet

Symfony havaitsee yhteyden aikana, mitä palomuuria tulisi käyttää. Tämän jälkeen ja jopa ennen ohjaimeen pääsyä suoritetaan pääsyn tarkistus. Ne on määritelty tiedostossa security.yml,

Sensio suosittelee:

  1. suojata "reuna-URL-mallejamme", ymmärtää globaaleja mallejamme (esimerkki: /admin);
  2. Käytä huomautuksia @Turvallisuus niin paljon kuin mahdollista ;
  3. Tarkista käyttäjän oikeudet palvelun kautta turvallisuus.konteksti (Symfony 2.6:n jälkeen palvelu on kehittynyt, katso tästä);
  4. Määritä äänestäjät hallitsemaan liikenneturvallisuutta helposti;
  5. Käytä ACL hallita objekti- ja käyttäjäoikeuksia.

Käytä @Security-merkintöjä

Sensio suosittelee @Security-merkinnän käyttöä.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
käyttää SensioNiputtaaFrameworkExtraBundleKonfigurointiReitti;
käyttää SensioNiputtaaFrameworkExtraBundleKonfigurointiTurvallisuus;
//…
/ **
* Näyttää lomakkeen, jolla luodaan uusi viestikokonaisuus.
* @tie("/uusi", nimi="admin_post_new")
* @Turvallisuus("has_role('ROLE_ADMIN')")
*/
julkinen toiminto uusi toiminta()
{
//…
}

Käytä lausekkeita tehdäksesi rajoituksista monimutkaisempia

Sensio selittää meille, että tämä annotaatio mahdollistaa myös monimutkaisempien ehtojen generoinnin, kuten kahden objektin kahden attribuutin vertailun. Tämä huomautus saattaa edellyttää ParamConverter.

Löydät lisätietoja asiakirjasta:

  • Luo lausekkeita
  • Muunna attribuutit objekteiksi

Pääsyn suojaus Twigissä

Jos haluat verrata yhdistettyä käyttäjää kohteen käyttäjään, pääset käsiksi Twig the lähettämä Käynnissä.

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

Hallitse turvallisuuttasi helposti

Tietoturvan hallinta on usein herkkä osa, ja koodimme järjestäminen on olennainen osa sovelluksemme onnistunutta turvaamista. Käyttö Äänestäjät on erittäin suositeltavaa. Muita tapoja järjestää koodisi voidaan harkita. Voimme esimerkiksi siirtää päätöksen kokonaisuutemme menetelmään.

Voit tarkastella Sensio-esimerkkiä sivulla 40.

Tämä osa on hyvin vähän yksityiskohtainen verrattuna Symfonyn tarjoamiin mahdollisuuksiin. Suosittelen sinua lukemaan hieman lisää dokumentaatiota tästä osasta, jos sinulla on turvallisuustehtävä.

Verkkoresurssit

Omaisuuden avulla voimme hallita resursseja, kuten Javascriptia, CSS:ää, fos-fontteja, kuvia… niin, että ne ovat käytettävissä sivuiltasi.

Omaisuutesi on tallennettava verkkoon/kansioon
Tällä tavalla voit ladata resurssit malleihisi seuraavasti:

1
2
<linkkiä suht="tyylilehti" href=« {{ asset(‘css/bootstrap.min.css’) }}«  />
<käsikirjoitus src=« {{ asset(‘js/jquery.min.js’) }}« ></käsikirjoitus>

Säilytä julkinen verkkokansio ja kaikki siihen tallennettu.

Käytä Asseticia

Asseticilla on useita kiinnostuksen kohteita, kuten tiedostojen kokoaminen. Esimerkiksi Less-, Sass-, TypeScript-tiedostot… Tästä syystä kansio verkko ei voi sisältää tiedostoja, kuten tiedostoja .Vähemmän.

Käytä Asseticia resurssien kokoamiseen, yhdistämiseen ja pienentämiseen, ellet käytä GruntJS:ää.

Lue lisää Asseticista

Assetic on täydellinen työkalu joistakin haitoista huolimatta. Löydät tämän moduulin dokumentaatiot alla olevien linkkien kautta:

  • Käytä Asseticia
  • Pienennä CSS ja JS
  • Pakkaa kuvat
  • Katso virallinen dokumentaatio

Aseta testit

Useimmat kehittäjät pitävät testaamista välttämättömänä. Silti vain vähemmistö toteuttaa niitä.

Katsotaan kuinka Sensio neuvoo meitä suorittamaan testimme.

Suorita yksikkötestejä

Yksikkötestejä käytetään toiminnallisten testien suorittamiseen, jotka puolestaan ​​testaavat sovelluksesi logiikkaa. Symfony ei ole määrittänyt mitään erityisiä työkaluja testien testaamiseen. Työkalut PHPUnit et PhpSpec lainataan.

Suorita toimintatestejä

Hyvien skenaarioiden luominen toiminnallisille testeille on välttämätöntä, ja silti kehittäjät kohtaavat nopeasti ongelmia niiden toteuttamisessa.

Määritä toimintatesti, jolla testataan, onko sivusi latautunut oikein.

Yritä käyttää kovakoodattuja URL-osoitteita sen sijaan, että luot niitä generaattorin kautta.

Testaa JavaScriptin toimivuutta

On olemassa monia työkaluja, kuten Minkki (PHPUnit-kirjasto) ja CasperJS.

Luo tietojoukkoja

Tämä on usein tietojoukkoja luovien kehittäjien huolenaihe.

Sensio suosittelee kirjastojen käyttöä Faker et Alice.

Yhteenveto

Tämä artikkeli on otettu kohteesta Parhaat käytännöt varten Symfony. Vaikka tämä artikkeli pysyy yksinkertaisena, sen tarkoituksena on purkaa 50 sivua neuvoja uusien Symfony-kehittäjien ohjaamiseksi.

★ ★ ★ ★ ★