Seri tulisan Django Bagian Satu: Perkenalan
Disclaimer:
Tulisan ini adalah salah satu metode saya untuk mengingat kembali tentang django, semoga dengan menuliskan di sini saya bisa jauh lebih ingat daripada sekadar membaca dokumentasi, singkatnya ada 3 poin yang membuat saya ingin menulis seri tentang django.
- Sebagai catatan pribadi
- Sebagai tambahan informasi syukur-syukur ada orang yang mampir ke blog ini
- Sebagai tempat diskusi jika memungkinkan jika salah satu pembaca ternyata mengoreksi pemahaman saya di kolom komentar
Sebelum memulai, saya tidak akan memulai dari install python maupun install virtual env, saya asumsikan sudah pernah atau setidaknya familiar, tulisan ini akan berfokus di django dan mungkin package-package pendukungnya. Mari mulai, Bismilah.
Django
Apa itu Django? Menurut dokumentasi resminya
Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. Built by experienced developers, it takes care of much of the hassle of web development, so you can focus on writing your app without needing to reinvent the wheel. It’s free and open source
Atau sederhananya, django merupakan web framework dari bahasa Python yang mendukung dalam pengembangan aplikasi yang cepat dan “clean”. Kenapa memilih django? Berdasarkan pengalaman saya, ada dua hal yang kenapa lebih memilh django dibanding framework yang lain, yaitu:
Cepat: Konteks cepat ini dalam proses development, karena fitur-fitur esensial untuk sebuah aplikasi sudah banyak disediakan oleh django seperti auth dan role management atau access control list (acl). Sehingga kita bisa fokus ke fitur yang akan kita buat.
Aman: Memang tidak ada yang 100% aman, tapi django setidaknya sudah implementasi pengamanan dasar yang sering dibuat seperti csrf, xss, sql injection dll.
Web Framework
Web framework menurut saya merupakan sebuah paket atau kumpulan library atau tools yang bertujuan untuk mempermudah proses pengambangan sebuah aplikasi web.
MVC
Sebuah pattern atau pola yang umum digunakan di web framework adalah MVC, MVC ini sederhananya adalah pembagian tugas kepada masing-masing bagian sesuai namanya MVC (Model, View, dan Controller)
Model: Bagian ini merupakan bagian yang bertanggung jawab terhadap data atau yang berhubungan dengan database.
View: Bagian ini adalah bagian yang merepresentasikan tampilan, bagaimana data dilihatkan. Umumnya bagian ini bagian yang dekat dengan UI/UX.
Controller: Bagian ini adalah bagian di mana logic pemograman atau logic feature disimpan.
Secara garis besarnya alur kerja sebuah web MVC seperti diagram di bawah ini.
MVC di Django
Ada sedikit perbedaan untuk MVC di django, di django disebutnya MVT: Model, View, Template. Untuk view-nya sendiri memang berbeda dengan MVC pada umumnya, di django pembagian tanggung jawabnya sebagai berikut:
Model: Masih sama dengan MVC pada umumnya, bagian ini bertanggung jawab pada data dan database.
View: Di django view ini lebih mirip dengan controller tempat logic pemograman/fitur yang akan dibuat.
Template: Bagian ini mirip “view” pada MVC pada umumnya, bagian ini banyak berkaitan dengan UI/UX.
Sempet bingung kenapa gak pake nama yang umum MVC tapi milih MVT, dan di situs resmi django dijawab seperti ini
Well, the standard names are debatable.
In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction.
So, in our case, a “view” is the Python callback function for a particular URL, because that callback function describes which data is presented.
Furthermore, it’s sensible to separate content from presentation – which is where templates come in. In Django, a “view” describes which data is presented, but a view normally delegates to a template, which describes how the data is presented.
Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
If you’re hungry for acronyms, you might say that Django is a “MTV” framework – that is, “model”, “template”, and “view.” That breakdown makes much more sense.
At the end of the day, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that’s most logical to us.
Istilah di Django
Ada dua istilah yang sering ditemui di django: project dan app
Project: Mengacu kepada keseluruhan aplikasi
App: Submodule dari projek itu tersendiri
Contohnya seperti ini, jika kita membuat aplikasi blog dan di dalam blog memiliki app artikel, maka struktur django akan seperti ini
blog: Projek
articles: app
Berikut adalah contoh struktur folder awal sebuah django dengan contoh yang disebutkan di atas.
Project
Umumnya isi folder projek berisi berkas utama terkait konfigurasi untuk projek itu sendiri, setidaknya ada 4 berkas: asgi.py, wsgi.py, settings.py, dan urls.py. Biasanya yang banyak diubah itu dua settings.py dan urls.py
Settings.py
Sesuai namanya ini untuk melakukan setting (konfigurasi), banyak hal yang bisa diatur di berkas ini, tapi setidaknya yang sering diubah yaitu:
Database: untuk mengatur projek ini akan diarahkan ke database apa, bawaannya menggunakan sqlite
Instaled apps: Konfigurasi untuk menentukan dalam projek ini “app” apa saja yang akan digunakan
Debug: Menentukan tipe aplikasi sedang berjalan apakah mode debug dimunculin atau tidak
Masih ada beberapa konfigurasi lainnya, tapi umumnya 3 hal itu yang paling sering disentuh.
App
Untuk app sendiri default atau bawaan saat membuat app baru akan terdiri dari folder migrations, apps.py, models.py, views.py, tests.py, dan admin.py
Folder Migrations: Folder untuk menampung berkas migrations (ini dibahas lebih lanjut di tulisan yang berbeda)
apps.py : Registry untuk app itu sendiri
models.py: Berkas ini akan berisi informasi struktur data yang dibutuhkan, sederhananya isi dari berkas ini akan merepresentasikan tabel di database
views.py: Berkas ini bertindak sebagai “controller” di konsep MVC
tests.py: Jika kita hendak membuat unit test, maka berkas ini yang digunakan
admin.py: Django datang dengan default admin dashboard, berkas ini bertugas untuk mendaftarkan app kita di halaman admin
Untuk penjelasan detail akan dibahas di tulisan terpisah.
Jadi, setiap “app” di django akan mempunyai struktur default yang sama, dan asumsinya jika “app” itu berdiri sendiri kita bisa dengan mudah menggunakan app yang sama di projek yang berbeda.
Tulisan seri django pertama selesai, jika pas dibaca ada yang dirasa kurang tepat atau mungkin salah, silahkan koreksi di kolom komentar ya. Terima kasih
referensi:
https://towardsdatascience.com/everything-you-need-to-know-about-mvc-architecture-3c827930b4c1
https://docs.djangoproject.com/en/3.2/faq/general/