Django vs. Pengontrol Tampilan Model [ditutup]

110

Dapatkah seseorang menjelaskan kepada saya dimana perbedaan antara Django dan pola Model View Controller?

Secara fungsional, apa yang dapat kita harapkan dari perbedaan itu - yaitu apa yang bekerja secara berbeda membandingkan Django dengan, misalnya, Ruby on Rails?

django model-view-controller frameworks

— Leonardo
sumber

2

Saat Anda mengatakan "" Model View Controller, apakah yang Anda maksud adalah pola umum, atau implementasi tertentu (seperti Ruby on Rails)?

— Paul D. Waite

33

Pertanyaan ini tidak memenuhi syarat sebagai 'tidak konstruktif' & memiliki jawaban langsung tanpa "debat, argumen, jajak pendapat, atau diskusi panjang". Lalu mengapa ditutup?

— pengguna

6

tidak konstruktif? SO super mods menyerang lagi.

— Amit Tripathi

4

Sampai hari ini, hampir 24.000 orang menganggap pertanyaan ini konstruktif. Termasuk diriku sendiri.

— frozenjim

3

Pada 2017, pertanyaan ini masih konstruktif

— Leonardo Pessoa

140

Menurut Buku Django , Django mengikuti pola MVC cukup dekat untuk disebut kerangka MVC.

Django telah dirujuk sebagai kerangka kerja MTV karena pengontrol ditangani oleh kerangka itu sendiri dan sebagian besar kegembiraan terjadi dalam model, templat dan tampilan.

Anda dapat membaca lebih lanjut tentang MTV / MVC di sini:

Pola Pengembangan MTV (atau MVC)

Jika Anda familiar dengan kerangka kerja pengembangan Web MVC lainnya, seperti Ruby on Rails, Anda dapat mempertimbangkan tampilan Django sebagai pengontrol dan cetakan Django sebagai tampilan .

Ini adalah kebingungan yang tidak menguntungkan yang disebabkan oleh interpretasi MVC yang berbeda.

Dalam interpretasi MVC Django, tampilan mendeskripsikan data yang disajikan kepada pengguna; bukan hanya tampilan datanya, tetapi data mana yang disajikan.

Sebaliknya, Ruby on Rails dan kerangka kerja serupa menyarankan bahwa tugas pengontrol termasuk memutuskan data mana yang akan disajikan kepada pengguna, sedangkan tampilan secara ketat adalah bagaimana tampilan data, bukan data mana yang disajikan.

— Paolo Moretti
sumber

6

Terima kasih atas jawaban yang bagus. Datang dari Rails ke Django, ini menjawab salah satu hal yang menurut saya paling membuat frustrasi: mengapa django meletakkan kode pengontrol dalam sebuah berkas bernama views.py !?

— dgmdan

@dgmdan Ini hanya konvensi default, Anda dapat memilih nama yang Anda suka. Tapi saya setuju, sepertinya aneh :)

— Paolo Moretti

1

Saya lebih suka meninggalkan views.py sebagai layer tampilan dan membuat satu set kelas kontroler ke dalam paket kontroler untuk menghindari kebingungan Django.

— stanleyxu2005

5

@dgmda: Karena konsep "controller" adalah istilah yang salah di webapps. MVC adalah kerangka kerja yang digerakkan oleh peristiwa yang tidak hanya cocok dengan model PERMINTAAN / RESPONS stateless HTTP. Ini seharusnya tidak disebut MVC di tempat pertama. Hampir semua webapp bukan MVC, tetapi menggunakan model dan fungsi atau kelas yang biasa disebut View. Tampilan pada gilirannya dapat mendelegasikan rendering HTML ke Template, tetapi tidak perlu. Jadi sebenarnya tidak ada pengontrol.

— Lennart Regebro

2

Saya mendukung konsep Lennart Regebro bahwa model stateless seperti HTTP seharusnya tidak memiliki pengontrol dan model MVC untuk aplikasi web hanya menimbulkan kebingungan besar

— Hussam

23

FAQ Django sendiri merupakan tempat yang layak untuk memulai:

https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the -view-the-template-how-come-you-don-t-use-the-standard-names

Dalam interpretasi kami tentang MVC, "tampilan" mendeskripsikan data yang disajikan kepada pengguna. Ini belum tentu tampilan datanya, tetapi data mana yang disajikan. Tampilan menjelaskan data mana yang Anda lihat, bukan cara Anda melihatnya. Ini perbedaan yang halus.

...

Lebih lanjut, masuk akal untuk memisahkan konten dari presentasi - di mana template masuk. Dalam Django, sebuah "tampilan" menjelaskan data mana yang disajikan, tetapi tampilan biasanya didelegasikan ke template, yang menjelaskan bagaimana data disajikan.

Lalu, di mana letak "pengontrol"? Dalam kasus Django, mungkin kerangka itu sendiri: mesin yang mengirimkan permintaan ke tampilan yang sesuai, menurut konfigurasi URL Django.

Jika Anda haus akan akronim, Anda dapat mengatakan bahwa Django adalah kerangka kerja "MTV" - yaitu, "model", "templat", dan "tampilan." Kerusakan itu jauh lebih masuk akal.

Ingatlah bahwa "Model View Controller" hanyalah sebuah pola, yaitu upaya untuk menggambarkan arsitektur umum. Jadi pertanyaan yang lebih baik mungkin adalah “Seberapa baik Django cocok dengan pola Pengontrol Tampilan Model?”

— Paul D. Waite
sumber

3

Ini mungkin jawaban yang paling langsung.

— pengguna

11

Saat Anda membuat kode, tidak memikirkan nama bagian kerangka, tidak ada perbedaan susbtantif antara, misalnya RoR. Tetapi itu tergantung pada penggunaan yang Anda berikan models, karena pada Django mereka dengan mudah memuat beberapa logika yang pada kerangka lain akan tetap pada tingkat pengontrol.

Di viewDjango cenderung menjadi satu set kueri untuk mengambil data, dan meneruskannya ke templat.

— inigomedina
sumber

10

A viewsdi Django adalah sesuatu seperti controllerdi MVC dan templatedi Django lebih mungkinviews

— Roel

7

Di mvt, permintaan ke URL dikirim ke View. Tampilan ini memanggil ke Model, melakukan manipulasi dan menyiapkan data untuk keluaran. Data diteruskan ke Template yang diberikan sebagai respons. idealnya dalam kerangka web, pengontrol disembunyikan dari pandangan.

Di sinilah perbedaannya dari MVC: di mvc, pengguna berinteraksi dengan gui, pengontrol menangani permintaan dan memberi tahu model dan tampilan meminta model untuk menampilkan hasilnya kepada pengguna.

— Samuele Mattiuzzo
sumber