Filosofi rancangan¶
Dokumen ini menjelaskan beberapa dari filosofi dasar pengembang Django yang telah digunakan dalam membuat kerangka. Tujuannya adalah menjelaskan yang lampau dan memandu masa akan datang.
Keseluruhan¶
Kehilangan sambungan¶
Sasaran dasar tumpukan Django adalah loose coupling and tight cohesion. Bermacam lapisan dari kerangka jangan "mengetahui" tentang satu sama lain meskipun sangat butuh.
Sebagai contoh, sistem cetakan tidak mengetahui tentang permintaan jaringan, lapisan basisdata tidak mengetahui tentang data ditampilkan dan sistem tampilan tidak peduli sistem cetakan mana yang digunakan seorang pemrogram.
Meskipun Django datang dengan tumpukan penuh keyakinan, potongan dari tumpukan adalah berdiri sendiri dari lainnya sedapat mungkin.
Kode sedikit¶
Aplikasi Django harus menggunakan sedikit kode sebisa mungkin; mereka kekurangan boilerplate. Django harus mengambil keuntungan penuh dari kemampuan dinamis Phyton, seperti interospeksi.
Pengembangan cepat¶
Titik dari kerangka kerja jaringan dalam abad 21 adalah membuat aspek membosankan dari pengembangan jaringan cepat. Django harus mengizinkan pengembangan jaringan cepat yang luar biasa.
Jangan Ulangi Diri anda (JUDA)¶
Setiap konsep berbeda dan/atau potongan data harus berada dalam satu, dan hanya satu, tempat. Pengulangan adalah buruk. Normalisasi adalah bagus.
Kerangka, dalam alasan, harus menyimpulkan sebanyak mungkin dari sekecil mungkin.
Lihat juga
Eksplisit lebih baik dari pada implisit¶
Ini adalah prinsip inti Phyton terdaftar di PEP 20, dan itu berarti Django tidak harus melakukan banyak "magic." Magic jangan terjadi meskipun terdapat alasan sangat bagus. magic adalah berharga menggunakan jika dia membuat kenyamanan besar tidak terjangkau di jalan lain, dan dia tidak diterapkan di jalan yang membingungkan pengembang yang mencoba mempelajari bagaimana menggunakan fitur.
Konsistensi¶
Kerangka harus konsisten pada semua tingkatan. Konsistensi berlaku ke semua dari tingkatan-rendah (menggunakan gaya pengkodean Phyton) sampai tingkatan-tinggi ("pengalaman" menggunakan Django).
Model¶
Eksplisit lebih baik dari pada implisit¶
Bidang jangan dianggap kebiasaan tertentu berdasarkan hanya pada nama bidang. Ini membutuhkan terlalu banyak pengetahuan dari sistem dan cenderung menjadi kesalahan. Malahan, kebiasaan harus berdasarkan pada argumen kata kunci dan, di beberapa kasus, pada jenis bidang.
Sertakan semua ranah logika yang terhubung¶
Model harus merangkum setiap aspek dari sebuah "obyek," mengikuti pola rancangan Active Record Fowler.
Ini mengapa kedua data dibawakan oleh model dan informasi mengenai dia (dia nama yang dapat dibaca manusia, pilihan seperti pengurutan awal, dll.) ditentukan di kelas model; semua informasi yang dibutuhkan untuk memahami model yang diberikan harus disimpan di dalam model.
API Basisdata¶
Sasaran inti dari API basisdata adalah:
Efesiensi SQL¶
Dia harus menjalankan pernyataan SQL sedikit waktu mungkin, dan dia harus mengoptimalkan pernyataan secara internal.
Ini adalah mengapa pengembang butuh memanggil save() secara eksplisit, dari pada kerangka menyimpan hal-hal dibelakang layar secara sembunyi.
Ini juga mengapa cara select_related() QuerySet ada. Dia adalah sebuah pilihan pendorong penampilan untuk kasus umum dari memilih "setiap obyek terkait."
Terse, sintaks kuat¶
API basisdata harus mengijinkan kaya, pernyataan ungkapan sebagai sintaks kecil sebisa mungkin. Itu harus tidak bergantung pada mengimpor modul lain atau obyek pembantu.
Penggabungan harus dilakukan otomatis, dibelakang layar, ketika dibutuhkan.
Setiap obyek harus mampu mengakses setiap obyek terhubung, sistem lebar. Akses ini harus bekerja dikedua cara.
Pilihan menjatuhkan kedalam SQL mentah dengan mudah, ketika dibutuhkan.¶
API basisdata harus menyadari jalan pintasnya tetapi tidak perlu akhir-semua-akan-semua. Kerangka harus membuatnya mudah untuk menulis SQL penyesuaian -- seluruh pernyataan, atau hanya klausa WHERE penyesuaian sebagai parameter penyesuaian ke pemanggilan API.
Rancangan URL¶
Kehilangan sambungan¶
URL di aplikasi Django tidak boleh bergandengan ke kode Phyton pokok. Mengikat URL ke nama fungsi Phyton adalah Hal Buruk Dan Jelek.
Bersama baris ini, sistem URL Django harus mengizinkan URL untuk aplikasi sama menjadi berbeda di konteks berbeda. Sebagai contoh, satu situs mungkin menaruh cerita pada /stories/, dimana lainnya mungkin menggunakan /news/.
Fleksibilitas tidak terbatas¶
URL harus sefleksibel mungkin. Apapun rancangan URL yang dipikirkan harus diizinkan.
Mendorong praktik terbaik¶
Kerangka harus membuatnya semudah (atau bahkan lebih mudah) untuk pengembang merancang URL cantik daripada yang jelek.
Berkas ekstensi dalam URL halaman-jaringan harus dihindari.
Koma gaya Vignette dalam URL pantas hukuman berat.
URL pasti¶
Secara teknis, foo.com/bar dan foo.com/bar/ adalah dua URL berbeda, dan robot mesin-pencari (dan beberapa alat analisa-lalu-lintas) akan memperlakukan mereka sebagai halaman terpisah. Django harus membuat sebuah usaha untuk "menormalkan" URL sehingga robot mesin-pencari itu tidak bingung.
Ini adalah alasan dibelakang pengaturan APPEND_SLASH.
Sistem cetakan¶
Pisahkan logika dari penyajian¶
Kami melihat sistem cetakan sebagai alat yang mengendalikan penyajian dan penyajian-logika terhubung -- dan itu dia. Sistem cetakan jangan mendukung fungsi yang pergi melebihi sasaran dasar ini.
Mencegah pengulangan¶
Kebanyakan dari situs jaringan dinamis menggunakan beberapa urutan rancangan situs lebar umum -- kepala umum, kaku, batang navigasi, dll. Sistem cetakan Django harus membuatnya mudah untuk menyimpan unsur tersebut dalam tempat tunggal, menghilangkan kode ganda.
Ini adalah filosoi dibelakang warisan cetakan.
Dipisahkan dari HTML¶
Sistem cetakan jangan dirancang sehingga dia hanya mengeluarkan HTML. Dia harus sama bagus pada membangkitkan bentuk berbasis-teks, atau hanya teks polos.
XML jangan digunakan untuk cetakan bahasa¶
Menggunakan mesin XML untuk mengurai cetakan memperkenalkan seluruh dunia baru dari kesalahan manusia dalam menyunting cetakan -- dan membuat sebuah tingkatan tidak diterima dari kelebihan pengolahan cetakan.
Menganggap kemampuan perancang¶
Sistem cetakan jangan dirancang sehingga cetakan perlu ditampilkan di penyunting WYSIWYG seperti Dreamweaver. Yang terlalu parah pembatasan dan tidak akan mengizinkan sintaks menjadi sebaik itu. Django mengharapkan cetakan penulis nyaman menyunting HTML secara langsung.
Perlakukan ruang kosong dengan jelas¶
Sistem cetakan jangan melakukan hal magic dengan spasi. Jika cetakan menyertakan spasi, sistem harus memperlakukan ruang kosong seperti dia memperlakukan teks -- tampilkan dia. Spasi apapun yang bukan berada di etiket cetakan harus ditampilkan.
Jangan menciptakan sebuah bahasa pemrograman¶
Sasarannya bukan untuk membuat bahasa pemrograman. Sasarannya adalah menawarkan cukup fungsi mirip-pemrograman, seperti percabangan dan perulangan, yang pada dasarnya untuk membuat keputusan penyajian-terhubung. Django Template Language (DTL) bertujuan untuk menghindari logika lanjut.
Keselamatan dan keamanan¶
Sistem cetakan, diluar kotak, harus melarang masuknya kode berbahaya -- seperti perintah yang menghapus rekaman basisdata.
Ini adalah alasan lain sistem cetakan tidak mengizinkan sewenang-wenang kode Pyton.
Diperpanjang¶
Sistem cetakan harus mengenali penulis cetakan lanjut mungkin ingin memperpanjang teknologinya.
Ini adalah filosofi dibelakang etiket cetakan penyesuaian dan saringan.
View¶
Kemudahan¶
Menulis tampilan harus semudah menulis fungsi Phyton. Pengembang jangan meng instantiate sebuah kelas ketika fungsi akan melakukannya.
Gunakan obyek permintaan¶
Tampilan harus mempunyai akses untuk meminta obyek -- sebuah obyek yang menyimpan metadata tentang permintaan saat ini. Obyek harus melewati secara langsung ke fungsi tampilan, dari pada fungsi tampilan mempunyai akses permintaan data dari variabel global. Ini membuat cahaya, bersih dan mudah untuk dicoba tampilan dengan melewatkan permintaan "tiruan" obyek.
Kehilangan sambungan¶
Sebuah tampilan jangan perduli tentang sistem cetakan mana pengembang gunakan -- atau bahkan apakah sistem cetakan digunakan sama sekali.
Membedakan diantara GET dan POST¶
GET dan POST berbeda; pengembang harus secara eksplisit menggunakan satu atau lainnya. Kerangka harus membuatnya mudah untuk membedakan diantara data GET dan POST.
Kerangka kerja Tembolok¶
Sasaran inti dari cache framework Django adalah:
Kode sedikit¶
Sebuah penyimpanan harus secepat mungkin. Oleh karena itu, semua kerangka kode dikelilingi backend tembolok harus menjaga minimal, khususnya untuk operasi get().
Konsistensi¶
API penyimpanan harus menyediakan antarmuka tetap terhadap backend penyimpanan berbeda.
Diperpanjang¶
API penyimpanan harus dapat diperpanjang pada tingkatan aplikasi berdasarkan pada kebutuhan pengembang (sebagai contoh, lihat Perubahan kunci cache).
