Najlepsze praktyki Symfony (oficjalna rekomendacja)
Agencja internetowa » Wiadomości cyfrowe » Najlepsze praktyki Symfony (oficjalna rekomendacja)

Najlepsze praktyki Symfony (oficjalna rekomendacja)

Kilka dni temu Fabien Potencier za pośrednictwem Sensio zaprezentował e-booka, w którym zebrano najlepsze praktyki i zalecenia dotyczące rozwoju projektu Symfony. Opracowany na podstawie zaleceń opublikowanych przez społeczność, celem tego dokumentu jest przedstawienie zestawu porad związanych z philoSophie z Symfony. Postaram się pokrótce podsumować 31 wskazówek opisanych w języku angielskim w tym poście.

Wprowadzenie

Ten dokument zaczyna się od kilku porad i kilku zdań, które mają nas zainspirować.

„Ten dokument nie jest samouczkiem”

Ten dokument został napisany z myślą o przeczytaniu go przez wszystkich programistów Symfony. Zarówno eksperci, jak i nowicjusze.

„Nie refaktoryzuj swoich aplikacji”

Od początku dokumentu jest wyraźnie wyjaśnione, że po tej lekturze nie powinniśmy aktualizować i refaktoryzować naszych aplikacji, aby idealnie pasowały do ​​wielu rekomendacji Sensio. Możemy zatem od razu nawiązać do pierwszych pomysłów rozwiniętych w dokumencie: te dobre praktyki powinny pozwolić nam uprościć nasze życie, a także uprościć przeglądanie kodu. Na poparcie moich uwag przytaczam trzy powody:

  • Twoje istniejące aplikacje nie są błędne, po prostu kierują się innym zestawem wskazówek;
  • Pełna refaktoryzacja bazy kodu jest podatna na wprowadzanie błędów w aplikacjach;
  • Ilość pracy włożonej w to można lepiej przeznaczyć na ulepszenie testów lub dodanie funkcji, które zapewniają rzeczywistą wartość użytkownikom końcowym.

Utwórz projekt

W rozdziale 2, który mówi o tym, jak zadeklarować i stworzyć projekt Symfony, podano pierwszą „Najlepszą praktykę”:

_Zawsze używaj Composera. _Composer wprowadził podstawy nowoczesnego PHP poprzez rozpoznawanie zależności. Dzięki niemu zależności zarejestrowane w pliku composer.json zostanie rozwiązany i repatriowany w twoim projekcie, aby nadawał się do użytku. Ponadto można łatwo aktualizować.

W ten sposób możesz uszanować strukturalną organizację projektu Symfony. (patrz strona 8).

Przykłady:

  • aplikacja/pamięć podręczna będzie przechowywać pamięć podręczną;
  • aplikacja/logi dzienniki przechowywania;
  • aplikacja/Zasoby będzie przechowywać szablony, a także globalne tłumaczenia dla Twojej aplikacji;
  • src / przechowywać pakiety aplikacji;
  • sprzedawca/ przechowuj zależności swojego projektu;
  • sieć/ będzie przechowywać zasoby (css, js, obrazy itp.), a także plik frontowy (app.php), umożliwiając późniejsze przekierowanie żądań do kontrolerów.
    W rezultacie nowa rekomendacja dotycząca pakietów. Bez przeprowadzania własnej analizy, która mogłaby podważyć philosophie z Symfony (czego nie chcę), oto zalecenie:

Utwórz pojedynczy pakiet AppBundle dla aplikacji. Wynika to ze sposobu, w jaki zaprojektowano Symfony. Każdy pakiet musi być samodzielny. _Powinni zatem mieć możliwość samodzielnego i niezależnego życia.

Pozostawiam was do rozważenia tej rekomendacji…

konfiguracja

Trzeci rozdział zawiera porady dotyczące konfiguracji jego aplikacji. Niektóre elementy konfiguracji mogą się różnić w zależności od systemu programistycznego i produkcyjnego.

Jak wskazuje zalecenie, musisz zatem zdefiniuj konfigurację związaną z Twoją infrastrukturą w pliku app/config/parameters.yml.

I odwrotnie, konfiguracja specyficzna dla twojego projektu, która będzie statyczna, zostanie zadeklarowana w app/config/config.yml.

Dodatkowo plik parametry.yml nie należy wersjonować. To jest plik parametry.yml.dist kim powinien być. To właśnie ten plik da Ci podstawowe opcje konfiguracji Twojej aplikacji. (zalecenie strona 12).

W rezultacie plik _app/config/config.yml _samo w sobie służy jako rekomendacja.

Ustaw konfigurację związaną z Twoją aplikacją w pliku app/config/config.yml
Zgodnie z tym zaleceniem zaleca się jednak wygenerowanie pliku config.yml, config_dev.yml i plik config_prod.yml. Pliki te są przeznaczone do przechowywania stałych specyficznych dla środowiska programistycznego i środowiska produkcyjnego.
Musimy uznać wartość za stałą, gdy jej wartość zmienia się bardzo niewiele.

Zastrzyk zależności

Oto jesteśmy! W trzecim rozdziale szczegółowo opisano zalecenia dotyczące korzystania z zależności. Radzę przeczytać tę rekomendację, jeśli moje wyjaśnienie wydaje ci się niejasne.

To zalecenie dotyczy wstrzykiwania usług do usług. Sensio zaleca zadeklarowanie ich w pliku src/AppBundle/Resources/config/services.yml.

Zapraszam również do przeczytania mojego artykułu o wstrzykiwaniu zależności oraz o tym, jak ograniczyć korzystanie z superkontenera usług.

Zadeklaruj logikę wewnętrzną

Rozdział 4 obejmuje organizowanie aplikacji. W zależności od Twoich potrzeb organizacja będzie się różnić. W przypadku funkcji globalnych i niebiznesowych firma Sensio zaleca umieszczenie ich w folderze Narzędzia lub po prostu wyjmij je z pakietu i umieść w osobnym folderze. W związku z tym zdecydowanie zaleca się zadeklarowanie swojej klasy jako usługi. Podana jest nowa rekomendacja, aby pomóc nam je zadeklarować.

Nazwa Twojej usługi powinna być jak najkrótsza, najlepiej jedno słowo.

Wybór formatu pliku

Będąc szczególnie przywiązanym do formatu Yaml w Symfony, wyobrażam sobie, że ten punkt wywoła niezgodę. Sensio bezkompromisowo rekomenduje używanie formatu Yaml w aplikacjach. Opracowane pakiety są współużytkowane przez dwa formaty: XML i Yaml.

Sensio zdecydował się polecić to drugie po prostu dlatego, że jest bardziej " łatwy w obsłudze ". Użycie innego formatu nie zmieniłoby sposobu działania aplikacji.

Nie definiuj zmiennej dla deklaracji swoich usług

Jest to praktyka, którą często zobaczysz w niektórych pakietach, a mimo to Sensio cię ostrzega. Oto przykład podany w książka kucharska :

1
2
3
4
5
6
7
8
#app/config/services.yml
# praca definition z przestrzenią nazw klasy jako parametrem
parametry:
slugger.class: AppBundleUtilsSlugger
usługi:
leniwiec:
klasa:
„%slugger.klasa%”

Oto przykład bezużytecznego kodu. Deklarowanie klasy do użycia dla usługi jest błędem, ponieważ ta zmienna mogłaby zostać użyta w innym miejscu kodu. Ponadto, i to jest powód podany przez Sensio, obciąża tworzenie serwisu.

Wybór ORM

Sensio zaleca korzystanie z Doctrine ORM w Symfony. Będąc użytkownikiem Doctrine, jego integracja z Symfony jest bardzo zaawansowana. Rezultatem jest rekomendacja, która na nowo uruchamia logiczną organizację naszych projektów. Deklaracja jednostki musi zawierać logikę wewnątrz pakietu. Patrz przykład na stronie 18.

Deklaracja mapowania

Deklarację mapowania Doctrine najlepiej przeprowadzić dzięki adnotacjom, które są zalecane w ramach Doctrine, ale także dla innych aplikacji.

Użyj adnotacji, aby zadeklarować mapowanie encji.
Przykład podano na stronie 19.

Montaż osprzętu

Sensio radzi, nie podając go do przodu, aby ustawić oprawy. Dla niewtajemniczonych są to zestawy danych, które będą domyślnie używane do uruchamiania aplikacji jeszcze przed wprowadzeniem jej do produkcji.

Standardy kodowania (koniec rozdziału 4)

To jest część, którą Sensio dziwnie prawie przyćmił. Mówię dziwnie, bo to dla mnie ważna część.

Symfony jest zakodowany zgodnie ze standardami PSR1 i PSR2. Te standardy muszą być promowane w społeczności programistów Symfony, ale także wśród programistów PHP. Symfony opublikowało artykuł, aby zebrać i podkreślić „ Standardy kodowania ". Lider Sensio, Fabien Potencier, umieścił również na GitHubie narzędzie do przeprowadzania kontroli zgodności ze standardami.

Kontrolery

Jeśli chodzi o kontrolery, Symfony's philosophie „cienkie kontrolery i grube modele”. Oznacza to, że kontrolery powinny pozostać lekkie. Każda metoda (akcja), do której uzyska się dostęp za pośrednictwem trasy, reprezentuje akcję. Kod dla każdej z tych metod musi być „lekki” oraz wywoływać i koordynować działania. Akcje te muszą być w usługach.

Ten model przedstawia sterownik jako używający kodów/części aplikacji.

Kontroler musi przestrzegać kilku zasad

  • Kontroler musi mieć maksymalnie 5 zmiennych.
  • Kontroler ma maksymalnie 10 akcji.
  • Każda akcja musi zawierać maksymalnie 20 wierszy.
    • Metoda może zawierać więcej niż 20 wierszy, pod warunkiem, że użytego kodu nie można rozłożyć na czynniki.

      Kontroler powinien dziedziczyć podstawowy kontroler Sensio FrameworkBundle i używać adnotacji do zarządzania trasami, buforowaniem i bezpieczeństwem.

      Zaleca się stosowanie adnotacji, ale dopuszczalne jest również stosowanie XML, YAML lub PHP. Aplikacja powinna używać tylko jednego formatu.

Nie używaj szablonu @Template

Jest to zalecenie dla mniej nieoczekiwanych, a jednak wyjaśnienie jest szczególnie mocne.

Nie używaj adnotacji @Template() do konfigurowania szablonu używanego przez kontroler
Wyjaśnienie jest proste, @Template używa TemplateListener, który jest wywoływany, gdy zdarzenie widok jądra Jest rzucony.
Podczas produkcji tego dokumentu przeprowadzono test. Użycie @Template zajmuje 26 ms przed uruchomieniem generowania, podczas gdy dla tej samej strony, która zostałaby wygenerowana przy użyciu „ $this->renderuj(…) », czas oczekiwania 5 milisekund.

Użyj adnotacji ParamConverter

Użycie tej adnotacji umożliwia zautomatyzowanie uwadniania podmiotu.

Korzystanie ze sztuczki ParamConverter jest dobre, gdy jest proste i wygodne.

Szablony

Rozdział 6 szczegółowo opisuje generowanie szablonu. Jest to bezproblemowe _co dokument daje nam w następstwie kilku zaleceń.

  • Użyj silnika szablonów Twig
    Sensio poleca Twiga z wielu powodów. Oprócz bycia silnik szeroko stosowany przez społeczność PHP, zarówno przez programistów PHP od zera, tylko przez programistów Symfony i inne frameworki. Podkreślana jest prostota, a promocja ich produktu jest wyraźnie widoczna. Wreszcie, Sensio gwarantuje wsparcie dla Symfony aż do wersji 3. Możesz także znaleźć pierwsze przejścia, które należy wykonać, aby przygotować swój kod do migracji do wersji 3.
  • Przechowuj szablony aplikacji w aplikacja/zasoby/widoki.
    Domyślnie programiści przyzwyczaili się do przechowywania swoich szablonów w folderze Zasoby każdego pakietu. To nie jest złe, ale Fabien Potencier zaleca przechowywanie globalnych szablonów dla twojej aplikacji we wspomnianym powyżej folderze.
  • Zdefiniuj swoje rozszerzenia Twig w AppBundle/Twig i skonfiguruj usługi w app/config/services.yml.
    Przedłużenia gałązek mają słabą widoczność. Te rozszerzenia, jakkolwiek bardzo przydatne, są czasami używane zbyt systematycznie. Sensio przedstawia tę część, którą uważam za niezbędną, jako sposób na wstrzyknięcie kodu biznesowego do swoich szablonów. Polecam przeczytać jak zadeklarować rozszerzenie Twig.

Formularze

Rozdział 7 zawiera instrukcje dotyczące korzystania z formularzy.

  • Zdefiniuj swoje formularze w klasach PHP.
    Symfony daje możliwość generowania klas PHP pozwalających na automatyczne generowanie formularzy dla danych podmiotów. TO Formularze jak się je nazywa, oferuje pełną integrację. Modyfikacja podmiotów jest wspomagana. Dodatkowo korzystanie z Formularzy umożliwia deportację zarządzania formularzami z szablonów.
  • Nie deklaruj przycisku, aby wysłać jego formularz.
    To zaskakujące, ponieważ ta funkcja została wprowadzona w Symfony 2.5. W momencie pisania tych słów Symfony 2.6 jest w trakcie akceptacji i dlatego nie zostało jeszcze oficjalnie wydane. Możemy zatem postawić kilka pytań dotyczących przydatności tej funkcjonalności, nie należy jej używać!Dlaczego warto dodawać przyciski w szablonach zamiast w Formularzach?
    W swoim wyjaśnieniu zespół Sensio wyjaśnia, że ​​chociaż ta funkcja pozostaje "przyjazny użytkownikowi" i że upraszcza wdrażanie formularzy, niektóre funkcjonalności pozostają ograniczone.
    Przykład, jeśli dodasz przycisk typu Zatwierdź z etykietą „Utwórz”, ten formularz nie może być ponownie użyty na stronie edycji. Będziesz wtedy musiał zadeklarować swoją formę jako usługę do wykonania spadku, co nie jest zalecane nieco dalej.
  • Nie używaj funkcji Twig formularz() i _formularzpoczątek().
    Utworzono część poświęconą renderowaniu szablonów. Uczy nas, że korzystanie z funkcji Twig formularz() I _ form_start()_ jest przestarzałe. Po raz kolejny jest to dla mnie błąd, ponieważ te funkcje były dostępne dopiero od niedawna.
    W Symfony istnieje kilka sposobów renderowania formularza. Spośród różnych sposobów renderowania najlepszy to taki, który zapewnia maksymalną elastyczność.
    Korzystanie z funkcji Twig wymienionych powyżej przynosi niewielkie korzyści. Sensio mówi o zwiększonej czytelności przy użyciu natywnych tagów HTML. Pomimo tego argumentu jest to niewielka korzyść… Bardzo mała!

Zadeklaruj swoje formularze jako usługi

Formularze są klasami PHP, co oznacza, że ​​można je zadeklarować jako usługi. Będziesz mógł zobaczyć tę metodę w pakietach Znajomi Symfony. Ta metoda nie jest zalecana przez Sensio, z wyjątkiem niektórych przypadków, które cytuję poniżej:

  • Jeśli chcesz ponownie użyć istniejących formularzy. Ustawienie dziedziczenia między dwoma formularzami pozwala ograniczyć przepisywanie wszystkich atrybutów.
  • Jeśli chcemy osadzić kolekcje encji.
    Korzystanie z formularzy jako usług w przypadku dodawania lub edytowania formularza nie jest zalecane, ponieważ użycie usługi ładuje plik @pojemnik. Ponadto trudno będzie zrozumieć, że z tej usługi korzysta administrator.

Dołącz (segregator) jego formularze

Ostatnio Sensio rozpoczął ciągłą migrację kodu Symfony2 do przyszłego kodu Symfony3. Wśród listy możliwych modyfikacji (wszystkie znajdziesz w UPGRADE-3.md) znajduje się nowe rozwiązanie dla lepiszcze żądanie wysłane przez formularz z forma który powstał. Nowa metodologia jest szczegółowo opisana na stronie 21 dokumentu Najlepsze praktyki.

Wypowiedz przedstawiony fragment:

1
2
3
4
5
6
7
8
9
10
11
12
13
publiczny funkcjonować nowośćAkcja(Poproś $prośba)
{
// zbuduj swój formularz
$form->handleRequest($request);
if ($form->isSubmitted() && $form->isValid()) {
$em = $ to->kontener->pobierz(„doctrine.orm.default_entity_manager”);
$em->persist($post);
$em->flush();
powrót $ to->przekieruj($ to->generujUrl(„admin_post_show”), szyk("ID" => $post->getId()));
}
}

Umiędzynarodowienie

Zadaniem modułu internacjonalizacji jest przetłumaczenie treści z jednego języka na inny, w zależności od regionu lub języka użytkownika. Bardziej niż dane rekomendacji, ten rozdział został napisany bardziej po to, aby pokazać możliwości w tej części, która zawsze pozostaje wrażliwa.

W rozdziale 8 redaktorzy opisują szczegółowo, jak aktywować tłumaczenie.

co z formatem

Symfony oferuje wiele formatów tłumaczeń:

  • PHP
  • Qt
  • .po
  • .mo
  • JSON
  • CSV
  • TO
  • i wiele innych

    Użyj formatu XLIFF dla plików tłumaczeń.
    Ten cytat jest oczywiście rekomendacją Sensio. Tak ale dlaczego ? Otrzymujemy krótką i precyzyjną odpowiedź.
    Spośród wszystkich obsługiwanych formatów tylko format XLIFF i format gettext są obsługiwane przez profesjonalne narzędzia tłumaczeniowe. Ponieważ XLIFF jest oparty na XML, korzysta z walidacji treści.
    Symfony 2.6 wprowadza nową funkcję umożliwiającą „komentowanie” (dodawanie notatek) w plikach XLIFF. To duża nowość, ponieważ generowanie plików tłumaczeniowych może sprawiać tłumaczom problemy ze zrozumieniem znaczenia zdania lub kontekstu, w jakim zostało użyte. Krótko mówiąc, XLIFF jest dobry!

Gdzie przechowywać nasze pliki tłumaczeń?

To pytanie wprowadza a Najlepsze praktyki. Sensio zaleca przechowywanie naszych plików w aplikacja/Zasoby/tłumaczenia.

Zwykle przechowujemy nasze tłumaczenia w każdym z naszych pakietów. To nie było złe, ale tłumaczenia są ogólnie uważane za globalne części naszych aplikacji, podobnie jak globalne szablony, dlatego Sensio zaleca przechowywanie ich w Aplikacja.

Jak tłumaczyć nasze aplikacje?

Zawsze używaj klawiszy do tłumaczenia treści.
na ten temat Najlepiej, nie będę się wypowiadał, bo mam niewielkie możliwości tłumaczenia aplikacji. Sensio radzi, aby przetłumaczyć słowo takie jak „Nazwa użytkownika”, należy użyć klucza takiego jak etykieta.nazwa użytkownika.

Przykład znajduje się na stronie 35.

Bezpieczeństwo

Rozdział 9 książki dotyczy centralnej części Symfony; bezpieczeństwo !

Symfony zostało zaprojektowane z myślą o łatwej konfiguracji i uwierzytelnianiu użytkowników, którzy chcieliby połączyć się z naszymi aplikacjami. Ta część jest bardzo złożona i pełna szczegółów, więc jest to ogólny zarys. Więcej dokumentacji można znaleźć na dedykowanej stronie.

Zadeklaruj swoje zapory ogniowe

Opcje konfiguracyjne należy wpisać do pliku bezpieczeństwo.yml która jest w aplikacja/konfiguracja.

Jeśli nie masz dwóch różnych połączeń z aplikacją (system i użytkownicy), zalecamy używanie tylko jednej zapory wejściowej z włączoną opcją anonimowości.
Wow wow wow! Czekaj, przybyłem na Symfony, nic nie zrozumiałem!

Co to jest zapora ogniowa?

Możesz znaleźć artykuł napisany w Wanadev, jak zadeklarować i skonfigurować natywne uwierzytelnianie w Symfony. W tym artykule szczegółowo opisano, czym jest zapora ogniowa.

Pojedynczy firewall? Dlaczego ?

Jeśli właśnie przeczytałeś artykuł, do którego link znajduje się powyżej, być może zauważyłeś, że zadeklarowano kilka zapór ogniowych.

W danym artykule były to trzy nazwiska dev, główny et Zaloguj Się. Pomimo tego, podana reguła jest przestrzegana, tylko zapora ogniowa może być uznana za bramę.

  • dev : ta zapora pozwala na pasek debugowania do wyświetlenia.
  • główny : ta zapora ogniowa jest nasza PUNKT WEJŚCIA. Anonimowi użytkownicy będą mogli zalogować się tak, jakby chcieli przestrzegać reguły. Wszystkie trasy zaczynające się od / będą używać tego wpisu.
  • Zaloguj Się : to jest zapora sieciowa. To będzie nasza brama w jednym przypadku: jeśli chcemy się połączyć. Jest to niezbędne, aby mieć dostęp do formularza logowania.
    Reguła jest więc przestrzegana.

Zdefiniuj kodowanie

Kodowanie haseł to kluczowa decyzja. Istnieje wiele algorytmów, takich jak sha (sha1, sha256, sha512, md5...).

Deklarując kodowanie (zobacz jak zadeklarować kodowanie) można podać trzy parametry.

  • Algorytm szyfrowania (domyślnie: sha512);
  • Liczba iteracji (domyślnie: 5000);
  • Kodowanie to base64 zakodowanego hasła (domyślnie: prawda).
    Pomimo tych domyślnych wartości, które zachęcam do modyfikacji, aby zmodyfikować je dla swoich aplikacji. Sensio zaleca również korzystanie z algorytmu bcrypt.

    Użyj kodowania bcrypt do szyfrowania haseł użytkowników.
    Sensio wyjaśnia, jak używać bcrypt. Obejmuje to solenie wartość. Ogranicza to ataki i jest bardziej odporne na ataki typu brute-force. Więcej szczegółów można znaleźć w powyższym artykule w Wikipedii.

Ustaw uprawnienia

Podczas połączenia Symfony wykrywa, która zapora ogniowa powinna zostać użyta. Następnie, a nawet przed uzyskaniem dostępu do kontrolera, przeprowadzana jest kontrola dostępu. Są one zdefiniowane w pliku bezpieczeństwo.yml,

Sensio poleca:

  1. chronić nasze „wzorce brzegowych adresów URL”, rozumieć nasze globalne wzorce (przykład: /admin);
  2. Użyj adnotacji @Bezpieczeństwo tak dużo jak to możliwe ;
  3. Sprawdź uprawnienia użytkownika za pośrednictwem serwisu bezpieczeństwo.kontekst (od Symfony 2.6 usługa ewoluowała, zobacz tutaj);
  4. Zdefiniuj wyborców, aby łatwo zarządzać bezpieczeństwem na drogach;
  5. Użyj ACL do zarządzania obiektami i prawami użytkowników.

Użyj adnotacji @Security

Sensio zaleca stosowanie adnotacji @Security.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
posługiwać się SensioZapakowaćFrameworkExtraBundlekonfiguracjaTrasa;
posługiwać się SensioZapakowaćFrameworkExtraBundlekonfiguracjaBezpieczeństwo;
//...
/ **
* Wyświetla formularz do tworzenia nowej encji Post.
* @Droga(„/nowy”, nazwa=”admin_post_new”)
* @Bezpieczeństwo("has_role('ROLE_ADMIN')")
*/
publiczny funkcjonować nowośćAkcja()
{
//...
}

Użyj wyrażeń, aby uczynić ograniczenia bardziej złożonymi

Sensio wyjaśnia nam, że ta adnotacja umożliwia również generowanie bardziej złożonych warunków, takich jak porównanie dwóch atrybutów między dwoma obiektami. Ta adnotacja może wymagać użycia Konwerter parametrów.

Więcej informacji znajdziesz w dokumencie:

  • Generuj wyrażenia
  • Konwertuj atrybuty na obiekty

Bezpieczeństwo dostępu w Twig

Jeśli chcesz porównać połączonego użytkownika z użytkownikiem obiektu, możesz uzyskać dostęp z Twig the użytkownik w toku.

1
2
3
{% if aplikacja.użytkownik… %}
...
{% endif %}

Łatwo zarządzaj swoim bezpieczeństwem

Zarządzanie bezpieczeństwem jest często delikatną częścią, a uporządkowanie naszego kodu jest istotną częścią pomyślnego zabezpieczenia naszej aplikacji. Sposób użycia Głosujących jest wysoce zalecane. Można rozważyć inne sposoby organizacji kodu. Na przykład możemy przenieść decyzję na metodę naszego podmiotu.

Możesz zobaczyć przykład Sensio na stronie 40.

Ta część jest bardzo mało szczegółowa w porównaniu z możliwościami, jakie oferuje Symfony. Radzę przeczytać trochę więcej dokumentacji na ten temat, jeśli masz do czynienia z zadaniem związanym z bezpieczeństwem.

Zasoby internetowe

Zasoby pozwalają nam zarządzać zasobami, takimi jak JavaScript, CSS, czcionki fos, obrazy… tak, aby były dostępne na Twoich stronach.

Twoje zasoby muszą być przechowywane w folderze web/
W ten sposób możesz załadować swoje zasoby do szablonów w następujący sposób:

1
2
<link rel=„arkusz stylów” href=« {{ asset(‘css/bootstrap.min.css’) }}«  />
<scenariusz src=« {{ asset(‘js/jquery.min.js’) }}« ></scenariusz>

Zachowaj publiczny folder internetowy i wszystko, co jest w nim przechowywane.

Użyj Assetica

Assetic ma wiele zainteresowań, takich jak kompilacja plików. Na przykład pliki Less, Sass, TypeScript… Z tego powodu folder sieć nie może zawierać plików takich jak pliki .mniej.

Użyj Assetic do kompilowania, łączenia i minimalizacji zasobów, chyba że używasz GruntJS.

Więcej informacji o: Assetic

Assetic to kompletne narzędzie pomimo pewnych wad. Dokumentację tego modułu można znaleźć, korzystając z poniższych łączy:

  • Użyj Assetica
  • Zminimalizuj CSS i JS
  • Kompresuj obrazy
  • Zobacz oficjalną dokumentację

Skonfiguruj testy

Testowanie jest uznawane przez większość programistów za niezbędne. Jednak tylko mniejszość je wdraża.

Zobaczymy, jak Sensio radzi nam przeprowadzać nasze testy.

Wykonaj testy jednostkowe

Testy jednostkowe służą do przeprowadzania testów funkcjonalnych, które z kolei przetestują logikę Twojej aplikacji. Symfony nie określiło żadnych konkretnych narzędzi do testowania twoich testów. Narzędzia PHPUnit et PhpSpec są cytowane.

Wykonaj testy funkcjonalne

Tworzenie dobrych scenariuszy testów funkcjonalnych jest niezbędne, a jednak programiści szybko napotykają problemy z ich wdrożeniem.

Zdefiniuj test funkcjonalny, aby sprawdzić, czy strona została załadowana poprawnie.

Spróbuj użyć zakodowanych na stałe adresów URL zamiast generować je za pomocą generatora.

Przetestuj funkcjonalność JavaScript

Istnieje wiele narzędzi, takich jak Norki (biblioteka PHPUnit) i CasperJS.

Generuj zestawy danych

Jest to często problemem dla programistów generujących zestawy danych.

Sensio zaleca korzystanie z bibliotek Faker et Alicja.

Wnioski

Ten artykuł pochodzi z Najlepsze praktyki dla Symfony. Pozostając prostym, ten artykuł ma na celu przeanalizowanie 50 stron porad, aby pomóc nowym programistom Symfony.

★ ★ ★ ★ ★