Di mana M dalam MVC?


14

Saya mencoba untuk memperbaiki aplikasi saya ke MVC, tapi saya terjebak di bagian M.

Dalam aplikasi yang didukung database, model diimplementasikan dalam kode aplikasi, kan?

Tapi kemudian, apa yang ada di database - bukankah itu modelnya?

(Saya tidak menggunakan database sebagai penyimpan objek sederhana - data dalam DB adalah aset perusahaan).


I'm not using the database as a simple object store. Saya menduga itu berarti beberapa logika bisnis dalam database, dalam bentuk prosedur yang tersimpan. Secara teori itu bertentangan dengan MVC, tetapi dalam praktiknya itu tidak masalah.
yannis

@YannisRizos - ada adalah BL di DB, tapi yang saya maksud dengan itu adalah bahwa saya ingin data di DB untuk memiliki kehidupan dan makna di luar aplikasi.

3
I want the data in the DB to have a life and meaning beyond the application.Apa?
yannis

2
@YannisRizos - Saya pasti akan menghargai bantuan untuk mengembalikan pernyataan itu. Data adalah aset perusahaan, bukan? Itu bukan milik aplikasi - jadi aplikasi tidak diizinkan untuk membuat beberapa model denormalized gila yang membuatnya sangat mudah untuk aplikasi , jika itu membuat menggunakan kembali data dari aplikasi lain sangat sulit. Ada saran?

1
Itu tidak akan menjadi masalah, jika ada format untuk apa pun yang ada yang perlu dibagikan, maka itu menjadi bagian dari persyaratan untuk format penyimpanan. Apa pun di masa depan yang membutuhkannya dalam format lain dapat memiliki tugas ETL, atau mengubahnya dalam DAL.
StuperUser

Jawaban:


46

Ya, baik model dalam kode dan basis data adalah "Model".

Model ini ada hubungannya dengan apa aplikasi Anda "IS", dan controller adalah apa yang "tidak". Setiap kode yang berhubungan dengan kegigihan langsung ke basis data dianggap sebagai Model.

Catatan: MVC adalah sebuah pola , jadi jangan terlalu memikirkannya. Sangat mudah untuk membuat semua super melakukan MVC dengan cara yang benar, tetapi pada akhirnya, itu hanya pola pikir! Ini berarti jauhkan logika bisnis Anda dari database dan UI - hanya itu. Sebelum MVC, orang-orang akan meletakkan semua logika bisnis di halaman web mereka ketika seharusnya berada di server, atau mereka akan memiliki banyak skrip yang diaktifkan dalam database yang melakukan business logic bersama dengan kode persistensi. MVC dibuat untuk membuat orang mulai berpikir dengan cara yang membantu membuat kode mereka dapat digunakan kembali, jadi jangan terjebak dalam detail terlalu banyak.


15
Jadi dari perspektif C dan V, bahwa ada database hanyalah detail implementasi dari M?

Pastinya. Diucapkan dengan baik.
herby

3
@MattFenwick Dari perspektif C dan V, tidak ada database. Anda menggunakan basis data lebih dari penyimpanan data, dalam istilah MVC, basis data hanyalah penyimpanan data. Tapi itu tidak masalah, jika itu sesuai dengan aplikasi Anda.
yannis

5
+1 untuk "jangan overthink mvc"
Javier

2
"jauhkan logika bisnis Anda dari database dan UI" - ini
David Murdoch

17

Trygve Reenskaug menulis makalah awal yang menggambarkan pola MVC pada tahun 1978. Model dalam uraiannya adalah model objek yang mewakili objek, fenomena, dan konsep dunia nyata. Dalam skenario aplikasi yang didukung database, model adalah proyeksi data Anda. Sederhananya, model adalah kelas dan hubungan mereka yang berkaitan dengan aplikasi Anda.

Dalam praktiknya, biasanya ada dua model yang digunakan dalam MVC, Model Domain (apa pemetaan ke database Anda) dan Model Aplikasi (juga disebut Model Tampilan dalam terminologi hari ini). Model Aplikasi adalah proyeksi Model Domain yang juga berisi tampilan data spesifik untuk menampilkan tampilan. Pendekatan ini disebut MMVC . Pengontrol langsung berinteraksi dengan model domain dan menyajikan model aplikasi ke tampilan. Dalam pola MVVM, Model Aplikasi dan Pengendali digabungkan.


+1: Saya suka jawaban ini yang terbaik. The model is a projection of your data.Basis data dirancang untuk menyimpan data dengan cara yang paling efisien untuk mengakses dan mengindeks. Model tersebut harus dirancang di sekitar domain bisnis.
Joel Etherton

Butuh waktu sedetik untuk kuurai the Domain Model (what's mapping to your database). Jawaban bagus!

2
+1 Ini adalah deskripsi yang bagus tentang berbagai rasa yang dikembangkan oleh MVC.
Ryan Hayes

Terima kasih kawan Saya telah menyelam jauh ke dalam hal-hal ini saat menulis buku saya. Senang itu masuk akal!
Michael Brown

3
  1. Anda tidak memerlukan database untuk MVC. Jika model Anda kebetulan berbicara dengan basis data, maka hebat. Itu juga bisa bertahan sendiri ke file datar, atau tidak bertahan sama sekali.

  2. Model adalah tempat data disimpan dalam memori di aplikasi Anda. Anda juga akan ingin menggunakan model untuk melakukan perhitungan dan validasi pada datanya. Misalnya, Anda memiliki model FinancePayment, dengan properti seperti suku bunga, jangka waktu, dan prinsip. Anda dapat menambahkan metode getMonthlyPayment () ke model Anda untuk menghitung pembayaran bulanan. Anda tidak ingin melakukan itu di controller atau view.

  3. Tampilan harus cukup bodoh, baik tidak memiliki logika sama sekali, atau hanya menggunakan pengikatan data sederhana (lihat pola Tampilan Pasif dan Pengawasan di situs Martin Fowler ). Tampilan memunculkan peristiwa ketika pengguna melakukan hal-hal, seperti mengklik tombol.

  4. Pengontrol bertanggung jawab untuk menangani peristiwa (menjalankan beberapa kode ketika pengguna mengklik tombol simpan), dan untuk mengatur properti model, dan memberi tahu model untuk memuat dan menyimpan sendiri (jika menggunakan kegigihan). Pengontrol seharusnya tidak melakukan perhitungan pada data model. Namun, dalam pengontrol, Anda dapat melakukan beberapa perhitungan atas nama tampilan, seperti "if model.profit () <0 maka widget.colour = 'red'"

  5. Anda harus dapat beralih ke versi baris perintah dari aplikasi Anda tanpa mengubah model, dan tanpa kehilangan fungsionalitas model.

Sebuah. Anda mungkin harus dapat beralih ke versi seluler aplikasi Anda (bukan versi desktop) dengan hanya mengalihkan tampilan (dan bukan pengontrol atau model). Anda harus dapat menguji unit model dan pengontrol Anda tanpa kerangka kerja pengujian GUI.


Tepat! Ini sangat jelas.

2

Model adalah kode yang memiliki koneksi ke V dan C di frontend, dan ke penyimpanan persisten (bisa berupa apa saja dari file ke database SQL / NoSQL) di backend. Bukan hanya kode yang memuat dari db dan menyimpan ke db (yang merupakan salah satu kesalahpahaman dari model), itu adalah kode yang benar-benar melakukan semua pekerjaan "domain" - memilih, memfilter, mengubah, menghitung, memutuskan atas data. Termasuk semua logika non-UI aplikasi.


Data mentah yang Anda inginkan tetap ada. Dalam organisasi apa pun yang paling cocok untuk model Anda. Model adalah API yang membuat logika aplikasi Anda hidup. Database itu adalah penyimpanan untuk data (tidak hidup). Jika memungkinkan untuk aplikasi Anda (saya tidak tahu jenis aplikasi apa itu), cobalah berhenti untuk menganggapnya sebagai "aplikasi yang didukung database", tetapi hanya "aplikasi", yang menggunakan database sebagai cara untuk mempertahankan data modul. Banyak masalah berasal dari "ikonisasi" database - itu tidak lebih dari penyimpanan data untuk model; Anda dapat membuangnya, merestrukturisasi atau menggantinya jika itu membantu.
herby

(di atas hanya berlaku untuk skenario ketika data dalam db tidak dibagikan dengan aplikasi lain)
herby

Saya meminta maaf atas pilihan kata yang buruk dalam komentar saya - yang ingin saya katakan adalah bahwa saya tidak yakin apa yang ada di database, sehubungan dengan MVC . Apakah basis data di luar MVC? Apakah itu bagian dari model? Apakah itu bagian dari V atau C (mungkin tidak, tetapi Anda mengerti maksudnya).

Saya melihat. Anda mungkin berasal dari jawaban saya bahwa Anda dapat melihatnya sebagai bagian dari model yang berfungsi untuk mempertahankan data aplikasi yang kode dari proses model. (Saya melihat EDIT): Jika database itu adalah sesuatu yang harus hidup lebih lama dari aplikasi, daripada melihat database sebagai layanan eksternal, model mana yang harus berkomunikasi dengan, mendapatkan data untuk perhitungan dan juga mengirim beberapa kembali.
herby

Dalam kasus ekstrem, ketika logika bisnis ada dalam DB itu sendiri, Anda dapat memiliki model yang sangat tipis yang sebagian besar relay ke DB, atau bahkan mengatakan bahwa db adalah model Anda (tetapi kemudian, harus memiliki semua logika).
herby

2

Mengambil pandangan yang sangat sederhana dan idealistis.

Model ini umumnya dilihat sebagai model domain (kira-kira, bisnis), bukan sebagai model data. Ini mungkin terlihat serupa, tetapi mereka tidak sepenuhnya terikat satu sama lain.

Tampilan harus menjadi model ujung depan aplikasi dan Pengontrol harus menjadi model aliran dari satu tampilan ke tampilan lainnya.

Logika bisnis harus sepenuhnya dirangkum dalam Model, apakah itu dalam database atau kode. Meskipun beberapa logika bisnis dapat diulang dalam View atau Controller, karena berbagai alasan, harus dimungkinkan (dan aman) untuk menghapus dua komponen sepenuhnya dan meletakkan front-end yang berbeda di tempatnya.


1

Menurut pemahaman saya, MVC hanyalah deskripsi dari pola arsitektur aplikasi klien Anda. Gambar di sini di Wikipedia hanya menunjukkan ini:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Tentu saja, ketika Anda memiliki bagian dari aplikasi Anda diimplementasikan dalam "prosedur tersimpan", maka kode basis data tersebut juga dapat menjadi bagian dari model, atau bahkan dari pengontrol (tergantung apa yang dikerjakan kodenya). Tetapi jika itu tidak terjadi, maka database jelas "di luar MVC", seperti yang Anda nyatakan.


1
But then, what is in the database -- is that not also the model?

Tidak, bukan itu. " Model mengelola perilaku dan data domain aplikasi". Seringkali, Model terhubung ke dalam database ya, tetapi tidak mungkin itu merupakan persyaratan. Model adalah lapisan baru antara aplikasi Anda dan basis data. Backend bisa berupa serangkaian objek Mock, XML, atau apa pun yang mendukung kegigihan data.

Dengan memisahkan lapisan yang Anda berikan pada diri Anda fleksibilitas yang jauh lebih besar untuk menggunakan praktik pengujian unit yang lebih baik, membuat kode lebih mudah dikelola (EG SQL digantikan oleh Oracle) di antara manfaat lainnya.

Hal yang sama berlaku dengan controller. MVC mendefinisikan controller sebagai perantara di antara dua lapisan. Tidak ada "lapisan bisnis" yang didefinisikan dalam MVC. Sebaliknya, Anda menambahkan milik Anda sendiri. MVC tidak merangkum semua lapisan yang diperlukan untuk membangun sebagian besar aplikasi. Itu hanya panduan umum untuk struktur dasar.

Pemisahan ini adalah kunci untuk memungkinkan inversi kontrol berfungsi.


+1 untuk jawaban yang sangat bagus dan sangat informatif; meskipun, saya menyarankan bahwa kalimat terakhir pantas dijelaskan. IoC belum tentu diketahui dan dipahami secara luas, sehingga mungkin menambah sedikit kebingungan. Penjelasan yang sangat berguna tentang apa yang Anda maksudkan dengan itu mungkin jauh di luar cakupan jawaban SE yang waras, tetapi itu benar-benar muncul pada saya.
Adam Crossland

Namun, jika Anda menempatkan logika bisnis Anda dalam prosedur tersimpan, maka ya, basis data mencakup model. (Secara pribadi, saya tidak akan merekomendasikan pendekatan itu.)
Roy Tinker

1
@Roy Tinker - Tidak, itu tidak masalah. Model secara konseptual terpisah. Akan ada entitas yang berintegrasi dengan basis data di suatu tempat di dalam lapisan. Entitas-entitas ini harus tetap dipisahkan dari entitas lain yang ada dalam model yang memiliki hubungan lain (Mock misalnya). Pengontrol harus melakukan panggilan ke Model sedemikian rupa sehingga tidak memiliki pengetahuan tentang bagaimana dan dari mana data berasal. Sebaliknya penentuan ini harus dibuat dengan injeksi dependensi dan IoC (pada dasarnya merupakan antarmuka yang dapat diikat ke backend yang berbeda, mengejek atau DB).
P.Brian.Mackey


0

Sebenarnya sangat sederhana, "Model" mewakili abstraksi untuk antarmuka data. Itulah mengapa:

  • Basis data dianggap sebagai bagian dari Model , tetapi bukan model itu sendiri
  • Data Model dapat berasal dari basis data, file, layanan web atau bahkan diejek.
  • Kelas model dalam MVC, HMVC, atau kerangka kerja serupa harus menyimpan kueri (lihat prinsip "model lemak, pengontrol kurus" [ 1 ] [ 2 ] [ 3 ])

Dan — jika saya benar — itulah sebabnya ketika seseorang merujuk pada model di luar konteks MVC, seseorang itu kemungkinan besar merujuk pada struktur data (yaitu skema ).


0

Saya pikir M berisi beberapa logika dan menyimpan data ke dalam DB. Kontroler memanggil modul mana yang akan dieksekusi dan modul ini akan mengeksekusi logika dan menyimpan data dalam DB (Mungkin memiliki lapisan persent) dan kemudian modul ini mengembalikan nilai ke V.


0

M (odel) dalam MVC harus menangkap model bisnis / domain di satu tempat.

Itu idealnya termasuk aturan bisnis dari domain serta struktur itu.

C (controller) sholuld idealnya hanya menyangkut dirinya sendiri dengan memediasi informasi model bisnis ke presentasi (misalnya View) dan menangkap input pengguna dari V (iew) untuk memulai perubahan dalam keadaan model.

Lapisan basis data hanya berurusan (atau lebih tepatnya hanya berurusan) dengan kegigihan keadaan model pada titik waktu tertentu.

Karena itu bukanlah sesuatu yang dimiliki baik Model atau Pengendali bagian dari pola MVC, melainkan merupakan masalah benar-benar terpisah yang dapat diimplementasikan secara implisit dengan transparan bertahan setiap perubahan model (sebagai fungsi dari fasad, memberikan interaksi dengan Model Anda ke Pengendali) atau seperti yang dilakukan lebih sering daripada tidak, dipanggil secara eksplisit oleh Pengendali setelah selesai membuat mutasi ke model.


0

Model di dunia yang ideal hanya boleh berisi logika bisnis, ia memodelkan beberapa objek nyata seperti Rumah. Namun dalam hampir semua keadaan model perlu untuk mempertahankan data ke beberapa penyimpanan.

Interaksi antara model dan data yang disimpan dapat terjadi pada lapisan data yang terpisah atau langsung dalam model, yang merupakan kasus ketika menggunakan ORM (Object Relational Mapper). Dengan kata lain baik model terhubung langsung ke database atau meneruskan data ke beberapa objek "akses data" lain yang terhubung ke database.

ORM (Object Relation Mapper) memetakan bidang dalam tabel database ke atribut objek model Anda, menyediakan getter dan setter. Dalam hal ini tidak ada lapisan data terpisah dan model bertanggung jawab langsung untuk mempertahankan datanya.

Berikut ini adalah contoh Ruby menggunakan ActiveRecordORM populer:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Priceadalah bidang dalam housestabel yang secara otomatis terdeteksi dengan ActiveRecordmenambahkan pengambil dan penyetel ke objek. Kapan savedisebut nilai atribut harga tetap ke database.

Dari sudut pandang saya, pro memiliki lapisan data adalah bahwa Anda mendapatkan titik di mana Anda dapat memanipulasi data sebelum sampai ke model, model memiliki lebih sedikit khawatir tentangnya, ia memiliki lebih sedikit tanggung jawab. Misalnya Anda mungkin perlu menggabungkan data dari beberapa sumber data yang tidak kompatibel, ini adalah sesuatu yang tidak mudah ditangani ORM.

Yang utama adalah lapisan abstraksi lain untuk dikelola, jika Anda tidak membutuhkannya, jangan repot-repot, tetap sederhana. Semakin sedikit bagian yang bergerak, semakin sedikit kesalahannya.


-1

Ya kamu benar.

(Pengendali Tampilan Model)

Arsitektur untuk membangun aplikasi yang memisahkan data (model) dari antarmuka pengguna (tampilan) dan pemrosesan (pengontrol).

Dalam praktiknya, pandangan dan pengontrol MVC sering digabungkan menjadi satu objek karena mereka terkait erat. Menurut MSDN

Pengontrol mengartikan input mouse dan keyboard dari pengguna, menginformasikan model dan / atau the view to change as appropriate.

Periksa diagram ini:

masukkan deskripsi gambar di sini

Misalnya, kode pengontrol memvalidasi permintaan data dan menyebabkannya dikembalikan dalam tampilan. Obyek view-controller terikat hanya dengan satu model; namun,a model can have many view-controller objects associated with it.


4
In practice, MVC views and controllers are often combined into a single object because they are closely related.Jika Anda melakukan itu, Anda salah melakukannya ...
yannis

Dari mana diagram itu? Dan dari mana definisi itu? Tolong jangan hanya menyalin barang tempel dari internet tanpa atribusi yang tepat.
yannis

@Yannis Rizos - Dia mengutip dokumentasi MS. Ini agak keluar dari konteks di sini, tetapi mereka mengatakan aplikasi non-web sering memiliki kopling tampilan / pengontrol, tetapi aplikasi web memiliki perbedaan yang sangat jelas. Ini mungkin salah satu alasan Anda tidak melihat MS mendorong MVC untuk aplikasi windows mereka (sebagai gantinya MVVM), hanya aplikasi web. msdn.microsoft.com/en-us/library/ff649643.aspx
P.Brian.Mackey

1
@ P.Brian.Mackey Saya curiga MS ada di balik ini: P
yannis

Saya telah mengedit jawaban Anda untuk menyertakan tautan @ P.Brian.Mackey yang disediakan. Tidak apa-apa mengutip sumber eksternal, tetapi Anda harus menyertakan tautan ke mereka. Juga MVVM mungkin sangat mirip dengan MVC, tapi itu bukan pola yang sama. Dalam MVC, pandangan dan pengontrol tidak boleh digabungkan menjadi satu objek ...
yannis
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.