‫Instruktur: Sampai saat
‫ini, kami baru saja menulis kode kami tanpa
‫berpikir banyak tentang arsitektur aplikasi kami.
‫Itu tidak terlalu penting sampai
‫sekarang, tetapi sekarang aplikasi kita benar-benar mulai tumbuh,
‫kita perlu
‫mulai mengkhawatirkan cara kita mendesain, atau mengkodekan arsitektur.
‫Dan kuliah ini hanya akan menjadi pengantar
‫singkat untuk arsitektur back-end.
‫Dimulai dengan arsitektur MVC.
‫Jadi, dalam proyek ini,
‫kita akan menggunakan arsitektur yang banyak
‫digunakan dan terkenal yang disebut model,
‫view, controller atau disingkat MVC.
‫Dan ada
‫berbagai cara untuk mengimplementasikan arsitektur MVC, beberapa
‫lebih kompleks daripada yang lain,
‫tetapi kami akan mengimplementasikannya
‫dengan cara yang sangat mudah di sini.
‫Saya hanya ingin memberi tahu
‫Anda bahwa jika Anda mencari MVC di
‫Google, Anda akan menemukannya diimplementasikan dalam beberapa cara berbeda.
‫Oke, bagaimanapun, dalam arsitektur ini, lapisan
‫model berkaitan dengan segala
‫sesuatu tentang data aplikasi, dan
‫logika bisnis.
‫Dan kita akan mempelajari apa arti logika bisnis
‫di slide berikutnya.
‫Selanjutnya, kita memiliki lapisan pengontrol
‫dan fungsi pengontrol adalah
‫untuk menangani permintaan aplikasi, berinteraksi
‫dengan model,
‫dan mengirim kembali tanggapan ke klien.
‫Dan semua itu disebut logika aplikasi.
‫Terakhir, lapisan tampilan diperlukan jika
‫kita memiliki antarmuka grafis di aplikasi kita.
‫Atau dengan kata lain, jika kita
‫sedang membangun situs web yang dirender sisi server,
‫seperti yang kita bicarakan sebelumnya.
‫Dalam hal ini, lapisan tampilan pada dasarnya terdiri
‫dari templat yang digunakan untuk
‫menghasilkan tampilan, sehingga situs web yang akan kita kirim kembali ke klien.
‫Dan itulah logika presentasi.
‫Untuk saat ini, kami baru saja
‫membangun API, jadi kami belum terlalu peduli dengan tampilan.
‫Itu untuk sedikit kemudian dalam kursus.
‫Jadi menggunakan pola, atau arsitektur seperti ini memungkinkan kita
‫untuk menulis aplikasi yang lebih modular, yang
‫akan jauh lebih mudah untuk dipelihara dalam
‫skala, jika diperlukan.
‫Dan kita bisa melangkah lebih
‫jauh, dan menambahkan lebih banyak lapisan abstraksi di sini.
‫Namun dalam aplikasi yang lebih kecil seperti
‫ini, arsitektur MVC sudah lebih dari cukup untuk kebutuhan kita.
‫Sekarang, semua ini mungkin
‫terdengar agak abstrak, jadi mari kita lihat MVC dalam
‫konteks aplikasi kita, dan siklus permintaan-tanggapan.
‫Jadi seperti biasa, semuanya dimulai dengan permintaan.
‫Permintaan itu akan mengenai salah satu router kami,
‫karena ingat, kami memiliki banyak router.
‫Pada dasarnya, satu untuk
‫setiap sumber daya, seperti tur, pengguna, dan lain-lain.
‫Sekarang tujuan dari router adalah untuk mendelegasikan permintaan
‫ke fungsi handler yang
‫benar, yang akan berada di salah satu controller.
‫Dan lagi, akan ada satu pengontrol
‫untuk setiap sumber daya
‫kami, untuk menjaga agar bagian-bagian berbeda dari aplikasi ini terpisah dengan baik.
‫Kemudian, tergantung pada permintaan yang masuk,
‫pengontrol mungkin perlu berinteraksi dengan
‫salah satu model,
‫misalnya untuk
‫mengambil dokumen tertentu dari database,
‫atau untuk membuat yang baru.
‫Sekali lagi, ada satu file model untuk setiap sumber daya.
‫Setelah mendapatkan data dari
‫model, pengontrol mungkin akan siap untuk mengirim kembali
‫respons ke klien, misalnya, yang berisi data tersebut.
‫Sekarang, jika kita ingin benar-benar membuat situs web, ada
‫satu langkah lagi yang terlibat.
‫Dalam hal ini, setelah mendapatkan data dari model,
‫pengontrol kemudian akan
‫memilih salah satu template tampilan dan memasukkan data ke dalamnya.
‫Situs web yang diberikan itu kemudian akan
‫dikirim kembali sebagai tanggapan.
‫Di lapisan tampilan di aplikasi
‫Express biasanya ada satu templat tampilan untuk setiap halaman.
‫Seperti halaman ikhtisar
‫tur, halaman detail tur, atau halaman login.
‫Dalam contoh aplikasi terbaru kami tentunya.
‫Jadi, itulah gambaran umum dari arsitektur yang akan
‫kita terapkan dalam proyek ini.
‫Sekarang untuk menyelesaikannya, izinkan saya
‫membahas sedikit lebih detail tentang model dan pengontrol.
‫Jadi, salah satu tujuan besar MVC
‫adalah memisahkan logika
‫bisnis dari logika aplikasi.
‫Anda akan mendengar tentang jenis logika ini setiap
‫saat ketika Anda menelusuri Stack
‫Overflow, atau beberapa situs seperti itu.
‫Tapi apa sebenarnya jenis logika ini?
‫Yah, perbedaannya sedikit berargumentasi, tetapi ini pendapat
‫saya: Jadi, logika aplikasi
‫adalah semua kode yang hanya berkaitan
‫dengan implementasi
‫aplikasi dan bukan masalah
‫bisnis mendasar yang sebenarnya
‫kami coba selesaikan dengan aplikasi .
‫Seperti menampilkan dan
‫menjual wisata, mengelola stok
‫di supermarket, atau mengatur perpustakaan, misalnya.
‫Jadi sekali lagi, logika
‫aplikasi adalah logika yang membuat aplikasi benar-benar berfungsi.
‫Misalnya, sebagian besar logika aplikasi di Express,
‫adalah tentang mengelola permintaan dan tanggapan.
‫Jadi, dalam arti tertentu, kita juga
‫dapat mengatakan bahwa logika aplikasi lebih banyak tentang hal-hal teknis.
‫Juga, jika kita memiliki tampilan di aplikasi
‫kita, logika aplikasi berfungsi
‫sebagai jembatan antara model dan lapisan tampilan
‫sehingga kita tidak pernah mencampur
‫logika bisnis dengan logika presentasi.
‫Baiklah?
‫Sekarang, tentang logika
‫bisnis, semua kode yang benar-benar memecahkan masalah
‫bisnis yang ingin kita pecahkan.
‫Katakanlah lagi, bahwa tujuan kami adalah menunjukkan tur kepada pelanggan
‫dan kemudian menjualnya.
‫Dan kode yang berhubungan langsung dengan aturan bisnis,
‫cara kerja bisnis,
‫dan kebutuhan bisnis, adalah logika bisnis.
‫Sekarang jika itu masih terdengar agak terlalu
‫filosofis, beberapa contoh dalam konteks aplikasi terbaru
‫kami adalah membuat tur baru di database aplikasi,
‫memeriksa apakah kata sandi pengguna sudah benar saat dia masuk,
‫memvalidasi data input pengguna, atau
‫memastikan bahwa hanya pengguna yang membeli tur tertentu
‫dapat meninjaunya.
‫Jadi semua hal ini berkaitan dengan bisnis itu sendiri,
‫dan itu adalah bagian dari logika bisnis.
‫Sekarang, kita perlu mengingat
‫bahwa logika aplikasi dan logika
‫bisnis hampir tidak mungkin untuk dipisahkan sepenuhnya, sehingga
‫terkadang keduanya akan tumpang tindih.
‫Tetapi kami harus melakukan
‫upaya terbaik kami untuk menjaga logika aplikasi
‫di pengontrol kami dan logika bisnis di model kami.
‫Dan bahkan ada filosofi
‫model gemuk, pengontrol tipis, yang
‫mengatakan bahwa kita
‫harus memasukkan logika sebanyak mungkin ke dalam
‫model, untuk menjaga pengontrol tetap sederhana dan ramping mungkin.
‫Jadi model gemuk akan memiliki logika bisnis
‫sebanyak yang dapat kita
‫bongkar, dan pengontrol tipis akan memiliki logika sesedikit
‫mungkin, sehingga pengontrol
‫benar-benar sebagian besar untuk mengelola permintaan dan
‫tanggapan aplikasi.
‫Oke?
‫Jadi, sekarang ingat semua ini
‫saat kami melanjutkan dan membuat aplikasi kami.