Filozofie projektowe¶
Ten dokument wyjaśnia podstawowe filozofie, którymi kierowali się deweloperzy Django podczas tworzenia frameworku. Celem jest wytłumaczenie przeszłości i pokierowanie przyszłością.
Ogółem¶
Luźne powiązanie¶
Fundamentalną zasadą stosu Django jest loose coupling and tight cohesion. Różnorodne warstwy frameworka nie powinny wiedzieć o innych więcej niż to absolutnie konieczne.
For example, the template system knows nothing about web requests, the database layer knows nothing about data display and the view system doesn’t care which template system a programmer uses.
Jednakże Django przychodzi z pełnym zestawem dla wygody, a części zestawu są ze sobą niezależne gdzie tylko to możliwe.
Mniej kodu¶
Aplikacje Django powinny używać tak mało kodu jak to możliwe. Django powinno w pełni wykorzystywać dynamiczne możliwości Pythona, tak jak w introspekcji.
Szybki rozwój¶
The point of a web framework in the 21st century is to make the tedious aspects of web development fast. Django should allow for incredibly quick web development.
Nie powtarzaj się (DRY)¶
Każdy unikalny pomysł i/lub część danych powinny żyć w jednym i tylko jednym miejscu. Redundancja jest zła. Normalizacja jest dobra.
Framework, w granicach rozsądku, powinien domyślić się ile to możliwe z możliwe małej ilości danych.
Zobacz także
«Dyskusja o DRY w Portland Pattern Repository»
Wprost jest lepiej niż nie wprost.¶
To jest główna zasada Pythona zapisana w PEP 20, i oznacza że Django nie powinno wykonywać zbyt dużo „magii”. Magia nie powinna się zdarzyć bez naprawdę dobrego powodu. Magia jest warta użycia tylko jeśli stworzy ogromną wygodę nieosiągalną w inny sposób i nie zostanie zaimplementowana w sposób, który będzie dezorientował programistów próbujących nauczyć się jak ją wykorzystać.
Spójność¶
Framework powinien być na spójny na każdym poziomie. Spójność dotyczy każdego poziomu od niskiego (używania stylu programowaniu w Pythonie) aż po wysoki (doświadczenie z używania Django).
Modele¶
Wprost jest lepiej niż nie wprost.¶
Pola nie powinny przyjmować pewnych zachowań bazując jedynie na nazwie pola. To wymaga zbyt dużo wiedzy o systemie i jest podatne na błędy. Natomiast, zachowania powinny bazować na kluczowych argumentach i, w niektórych przypadkach na typie pola.
Uwzględnij całą istotną logikę domeny.¶
Modele powinny hermetyzować każdy aspekt obiektu, zgodnie z wzorcem projektowym Active Record, którego autorem jest Martin Fowler.
To jest powód dla którego dane zarówno reprezentowane przez model i informacje o nim (to jest nazwa czytelna dla człowieka, opcje jak np. domyślne sortowanie itp.) są trzymane w klasie modelu; wszystkie informacje potrzebne do zrozumienia danego modelu powinny być w nim przechowywane.
API baz danych¶
Podstawowymi celami API baz danych są:
Efektywność SQL¶
Powinno się wykonywać zapytanie SQL tak rzadko jak to możliwe, dodatkowo powinno się optymalizować zapytania wewnętrznie.
To jest powód dla którego programiści muszą odwołać się do save() wprost, a framework nie robi tego po cichu w tle.
To jest dodatkowy powód dlaczego metody select_related() QuerySet istnieją. Jest to opcjonalne poprawienie wydajności dla częstych przypadków wybierania „każdego powiązanego obiektu”.
Zwięzła, silna składnia.¶
Interfejs bazy danych API powinien udostępniać bogatą, wyrazistą składnię przy możliwie małych nakładzie kodu. Nie powinien polegać na importowaniu innych modułów lub pomocniczych obiektów.
Połączenia tabel powinny być wykonywane automatycznie, w tle jeśli jest to konieczne.
Każdy obiekt powinien mieć dostęp do każdego obiektu z którym jest w relacji, w danym systemie. Ten dostęp powinien być obustronny.
Możliwość łatwego przełączenia się na surowy SQL, kiedy to konieczne.¶
API bazy danych powinno zauważać, że jest to skrót a niekoniecznie wszystko. Framework powinien ułatwiać pisanie spersonalizowanego SQL - całych formuł lub tylko własnych klauzuli WHERE jako własne parametry na wywołania API.
Projekt URL¶
Luźne powiązanie¶
URLe w aplikacji Django nie powinny być połączone z podstawowym kodem Pythona. Łączenie URLi wraz z nazwami funkcji Pythona nazywa się Złą i Brzydką Rzeczą.
Poza tym, system URL Django powinien pozwalać, by adresy URL tej samej aplikacji były różne w zależności od kontekstu. Na przykład, jedna strona może przechowywać historie w /stories/, a inna może używać /news/.
Nieskończona elastyczność¶
URLe powinny być elastyczne jak to tylko możliwe. Każdy wyobrażalny URL powinien być dostępny.
Zalecane najlepsze praktyki¶
Framework powinien pozwalać programiście łatwo (albo nawet łatwiej) tworzyć ładne URLe niż brzydkie.
File extensions in web-page URLs should be avoided.
Przecinki w URLach zasługują na surową karę.
Ostateczne URLe¶
Technically, foo.com/bar and foo.com/bar/ are two different URLs, and
search-engine robots (and some web traffic-analyzing tools) would treat them as
separate pages. Django should make an effort to „normalize” URLs so that
search-engine robots don’t get confused.
To uzasadnia używanie ustawienia APPEND_SLASH
System szablonów¶
Oddzielenie logiki od prezentacji¶
Widzimy, że system szablonów jako narzędzie kontroli prezentacji i prezentacja zorientowana na logikę to jest to. System szablonów nie powinien wspierać funkcjonalności wykraczających poza ten cel.
Porzuć redundancje¶
Wiele z dynamicznych stron internetowych używa pewnego wspólnego sposobu projektowania - np. nagłówek, stopka, belka nawigacyjna itp. System szablonów Django powinien sprawić łatwym magazynowanie elementów w jednym miejscu, eliminując duplikaty kodu.
To jest filozofia przemawiająca za template inheritance.
Bądź oddzielony od HTML¶
System szablonów nie powinien być projektowany tylko jako generator kodu HTML. Powinien być równie dobry w generowaniu innych formatów bazujących na tekście lub po prostu zwykłym tekście.
XML nie powinien zostać użyty do języka szablonów.¶
Użycie silnika XML do prasowania szablonów wprowadza nowy świat błędów ludzkich w edycji szablonów – i stwarza nieakceptowalny poziom narzutu w przetwarzaniu szablonu
Zakładaj kompetencje projektanta¶
System szablonów nie powinien być zaprojektowany w taki sposób by szablony ładnie wyświetlały się w edytorach WYSIWYG takich jak Dreamweaver. To jest zbyt dużym ograniczeniem i uniemożliwiłoby składni bycie tak ładną jak jest teraz. Django oczekuje od twórców szablonu łatwości edytowania bezpośrednio HTMLa.
Traktuj białe znaki dosłownie¶
System szablonów nie powinien robić cudów z białymi znakami. Jeśli szablon zawiera biały znak, system powinien potraktować ten znak tak jak traktuje tekst - po prostu go wyświetlić. Każdy biały znak, który nie jest w znaczniku szablonu, powinien być wyświetlony.
Nie wymyślaj języka programowania¶
Celem jest to, by nie wymyślać języka programowania. Celem jest, by zaoferować na tyle programistyczno-podobnej funkcjonalności, takiej jak branching czy pętle, na ile jest to niezbędne do tworzenia decyzji związanych z prezentacją. Django Template Language (DTL) próbuje uniknąć zaawansowanej logiki.
Bezpieczeństwo i ochrona¶
System szablonów, w oryginale, powinien zabraniać wstawiania złośliwego kodu - takiego jak komendy usuwające rekordy w bazie danych.
To kolejny powód, dla którego system szablonów nie zezwala na standardowy kod w Pythonie.
Rozszerzalność¶
System szablonów powinien rozpoznawać że zaawansowani twórcy szablonów mogą chcieć rozszerzyć tę technologię.
To jest filozofia stoją za wyspecjalizowanymi tagami szablonów i filtrami.
Widoki¶
Prostota¶
Pisanie widoku powinno być tak proste jak pisanie funkcji w Pythonie. Developerzy nie powinni być zmuszeni do tworzenia klasy, kiedy wystarczy tylko funkcja.
Używaj obiektów zapytań¶
Widoki powinny mieć dostęp do obiektów zapytań - obiektów, które przechowują metadane o obecnym zapytaniu. Obiekt powinien być przekazywany bezpośrednio do funkcji widoku, nie powinna ona musieć korzystać z danych zapytania przez globalną zmienną. To czyni testowanie widoków przez przekazywanie ‚fałszywych’ obiektów zapytań lekkim, łatwym i przyjemnym.
Luźne powiązanie¶
Dla widoku nie powinno mieć znaczenia jakiego systemu szablonów używa developer - ani czy w ogóle używa jakiegoś systemu szablonów.
Różnice pomiędzy GET a POST¶
GET i POST są rozłączne; programiści powinni wprost użyć jednego lub drugiego. Framework powinien umożliwiać łatwe rozróżnienie między danymi pochodzącymi z GET lub POST.
Framework pamięci podręcznej¶
Głównymi celami Django cache framework są:
Mniej kodu¶
Pamięć podręczna powinna być szybką jak tylko to możliwe. Stąd też, cały kod frameworka otaczający backend pamięci podręcznej powinien być ograniczony do absolutnego minimum, w szczególności w przypadku metody get()
Spójność¶
API pamięci podręcznej powinno zapewniać spójny interfejs w zróżnicowanych pamięciach podręcznych backendów.
Rozszerzalność¶
API pamięci podręcznej powinno być rozszerzalne na poziomie aplikacji zależnie od potrzeb developera (dla przykładu, zobacz Cache key transformation).
