Perbedaan antara arsitektur 3-Tier dan MVC (Model, View Controller) di ASP.Net

Saya ingin tahu bagaimana arsitektur 3-Tier berbeda dari MVC (Model, View Controller) di ASP.Net seperti yang terlihat bagi saya bahwa arsitektur yang sama berlaku.

Dalam 3-tier kita memiliki User Services Layer, BusinessLayerdan DataAccessLayer, di sisi lain kita memiliki Model, View, dan Controller. Ini sepertinya arsitektur yang sama bagi saya.

Adakah yang bisa menjelaskan jika apa yang benar-benar berbeda dari dua arsitektur, bagaimana setiap lapisan berbeda satu sama lain?

Ini seperti menanyakan apa perbedaan antara apel dan inti apel. Kedua arsitektur ini tidak saling menggantikan. Saya pikir pandangan yang lebih akurat adalah bahwa arsitektur 3-tier menambah MVC.

Arsitektur MVC

• Model: Ini mewakili "barang" dalam aplikasi Anda. Lapisan ini telah menjadi sedikit kabur dalam beberapa tahun terakhir, seperti yang akan saya jelaskan nanti.

• Tampilan: Antarmuka pengguna. Hal yang berinteraksi dengan pengguna.

• Controllers: Kode pemrograman yang merespons pengguna dan perubahan pada lapisan model

Arsitektur 3 Tingkat

Dengan arsitektur 3-tier, Anda memiliki lapisan dengan tanggung jawab yang berbeda.

• Layanan Pengguna: (atau "layanan" secara umum) Lapisan ini lebih lanjut tentang mengoordinasikan pengambilan dan modifikasi dari lapisan "model". Tindakan multi-langkah yang rumit dapat dilakukan di sini

• Lapisan Bisnis: Ini mewakili aturan bisnis yang terukir dalam kode pemrograman. Apa yang "The Business" inginkan ditegakkan di lapisan ini.

• Lapisan Akses Data: Satu atau beberapa kelas yang bertanggung jawab untuk mengakses penyimpanan data yang persisten.

Satu-satunya bagian dari arsitektur 3-tier yang bersinggungan dengan MVC adalah "Business Layer". "Model" dalam MVC dan "Lapisan Bisnis" dalam arsitektur 3-tier berusaha mencapai tujuan yang sama.

"M" di MVC menjadi kabur

Lapisan "model" di MVC telah berkembang dalam beberapa tahun terakhir. Dari apa yang saya lihat, ada dua, mungkin tiga jenis model:

1. Model Domain: Ini mewakili "hal-hal" yang dipedulikan "Bisnis" - Domain Bisnis. Kelas-kelas ini menyimpan data dan semua prosedur yang beroperasi pada data itu untuk menegakkan aturan bisnis. Model Domain yang sering dikaitkan dengan tabel dalam database. Ini tampaknya sesuai dengan "Lapisan Bisnis" dari arsitektur 3-tier.

2. Lihat Model: Ini adalah kelas yang digunakan untuk memijat data dari model domain menjadi sesuatu yang lebih enak dilihat. Ini tidak cocok dengan arsitektur 3-tier mana pun karena model tampilan tidak menerapkan logika bisnis, juga tidak menyediakan layanan atau akses data apa pun.

3. Model Bisnis: Dalam aplikasi yang kompleks, kebutuhan untuk memisahkan Model Domain dari Logika Bisnis muncul. Model Bisnis berisi data dan prosedur yang beroperasi pada data tersebut untuk menerapkan aturan bisnis, dan Model Domain diturunkan ke "Tas Properti" - objek yang hanya menyimpan data tetapi tidak mengandung perilaku. Model Domain menjadi bentuk lain dari Objek Transfer Data antara database dan aplikasi.

Tidak ada di MVC adalah akses data yang disebutkan. Dalam beberapa kasus, Anda akan melihat bahwa akses data termasuk dalam "model" lapisan MVC, yang seperti yang telah kita lihat bukan lapisan yang jelas lagi. Sungguh saya melihat arsitektur 3-tier dipasangkan dengan MVC untuk membuat seluruh aplikasi. Satu menambah atau memperbaiki yang lain:

• Model
  • Model Domain (MVC / 3-tier)
  • Lihat Model (MVC)
  • (opsional) Model Bisnis (MVC / 3-tier)
• Tampilan (MVC)
• Pengendali (MVC)
• Akses Data (3-tier)
• Layanan (3-tier)

Ada beberapa persimpangan, tetapi mereka sebagian besar terpisah, dan bersama-sama digunakan untuk memisahkan dan mengisolasi berbagai komponen dari sistem yang lebih besar.

Tidak, mereka tidak sama.

MVC adalah pola desain untuk menyusun kode antarmuka pengguna. Ini dapat digunakan dalam arsitektur tiga-tier, dalam hal ini polanya akan berada di lapisan layanan pengguna. Tetapi juga dapat digunakan untuk UI dalam aplikasi yang bukan tiga tingkat - misalnya kalkulator tanpa kegigihan yang mendasarinya, dan karenanya tidak ada lapisan akses data.

Dalam arsitektur tiga-tier dengan frontend MVC, objek domain yang digunakan sebagai model akan menjadi objek dari lapisan bisnis, tetapi pola MVC tidak benar-benar menentukan objek seperti apa model tersebut, hanya peran mereka dalam pola tersebut. adalah. Misalnya dalam varian MVVM, modelnya adalah adaptor UI-specifc di atas objek domain. Dalam hal ini bahkan model termasuk dalam lapisan layanan pengguna.

Saya tahu akan ada banyak jawaban berbeda, tetapi saya akan memberikan pandangan saya tentang ini.

Ini jawaban paling terkenal dalam rekayasa perangkat lunak "Itu tergantung".

Pada dasarnya jika Anda melihatnya, selain berbagai implementasi dan perbedaan teoretis, ini adalah pola yang sangat mirip dengan aliran yang sama.

Di mana itu tergantung adalah aplikasi yang Anda buat, sebuah webapp sederhana mungkin hanya memiliki lapisan MVC berbicara melalui ORM ke DB. Yang lebih kompleks mungkin memiliki MVC yang menangani front-end di Layer Pengguna, dengan operasi yang tidak terpapar pengguna yang lebih kompleks terjadi di lapisan BL, dengan lapisan data yang terdiri dari banyak sumber.