# dokumentasi Django 2.2.9.dev20191202104323

# 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 tampilan data dan layar sistem tidak perduli sistem cetakan mana yang pemrogram gunakan.

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 Jaringan di abad 21 adalah membuat aspek membosankan dari pengembangan Jaringan cepat. Django harus mengizinkan untuk pengembangan luar biasa jaringan cepat.

### 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

obrolan DRY di Portland Pattern Repository

### 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 tambahan di 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 penganalisa lalu lintas Jaringan) akan emmperlakukan mereka sebagai halaman terpisah. Django harus membuat sebuah usaha untuk "menormalkan" URL sehingga robot mesin-pencari 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.

Sistem cetakan Django mengenali bahwa cetakan paling sering ditulis oleh perancang, bukan pemrogram, dan karena itu jangan mengangap pengetahuan Pyton.

### 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).