Mengapa semua orang menempatkan pengontrol di satu folder dan tampilan di yang lain?


36

Saya sedang bersiap-siap untuk mengambil tikungan dari asp dan ke dalam kerangka MVC, asp.net MVC atau nancy. Ke mana pun saya pergi, saya melihat folder untuk pengontrol / modul dan folder untuk dilihat. Apakah ini hanya refleks pavlovian tentang merapikan barang-barang berdasarkan tipe, atau adakah kebijaksanaan yang lebih dalam beroperasi? Saya punya sedikit proyek proof-of-concept di mana saya menyimpan bersama file-file yang kemungkinan besar akan saya buka bersama, kenyamanan yang luar biasa. Karena file-file ini juga cenderung saling memanggil, mereka dapat melakukannya dengan tautan yang lebih pendek, lebih rapuh, dan relatif. Pola ini ditantang oleh mvc, karena lintasan folder tidak lagi secara otomatis sesuai dengan lintasan url, dan, di asp.net mvc, templat dan perutean proyek menegakkan skisma views \ controllers \ schism.

Halaman microsoft ini memperkenalkan konsep area. Ini dapat dibaca sebagai pengakuan tentang bagaimana aplikasi besar menjadi sulit karena pemisahan buatan ini.

Orang akan menolak "pemisahan masalah", tetapi pemisahan masalah sudah dicapai dengan memiliki file sumber yang terpisah. Bagi saya, tidak ada keuntungan konkret, dari mengambil file sumber ini yang digabungkan secara ketat, dan mengirimkannya ke ujung yang berlawanan dari struktur folder?

Apakah ada orang lain yang memperjuangkan ini? Ada tips?


3
Anda tidak berpikir itu logis untuk memisahkan file kode back-end dari file tampilan? Jika kita sudah mengambil arahan mengapa tidak meletakkan file CSS dan JavaScript yang relevan di folder yang sama juga?
Alternatex

2
Jika Anda mendapatkan Resharper, maka F12 saat dipanggil ke Viewdalam pengontrol akan membawa Anda ke tampilan dan opsi pertama di menu klik kanan pada tampilan akan membawa Anda ke pengontrol, dan seluruh masalah dengan kurangnya navigasi hilang.
Pete Kirkham

4
@Alternatex Maaf, tapi saya tidak melihat bagaimana controller "back-end". Ini sangat erat dengan pandangan itu. Tampilan tidak baik tanpa controller, controller tidak digunakan tanpa view. Suatu hari Anda ingin menghapusnya bersama. Itu bagi saya adalah ujian terbaik dari apa yang dimiliki bersama dalam folder ?? Kecuali seseorang dapat menunjukkan kepada saya cara yang lebih baik?
bbsimonbb

2
Tampilan adalah lapisan presentasi. Pengontrol adalah lapisan yang berisi layanan, yang mungkin berisi objek dari domain Anda, yang berisi logika bisnis Anda, yang karenanya mengandung logika back-end aplikasi Anda. Tampilan hanya terdiri dari persyaratan sepele dan loop sederhana untuk iterasi atas koleksi, jika pandangan Anda mengandung sesuatu yang lain, Anda salah melakukannya. Seperti halnya struktur biasa, Anda telah memisahkan back-end dan front-end, yang bagi saya adalah struktur yang lebih baik daripada yang Anda sarankan.
Andy

10
Jadi tidak ada kekurangan orang untuk mengatakan kepada saya bahwa controller adalah barang pecah-belah sehingga masuk ke lemari barang pecah belah. Tampilan adalah kacamata sehingga mereka masuk ke lemari kaca. Saya tahu bahwa controller adalah barang pecah belah, tetapi saya mengusulkan akan lebih baik untuk memiliki lemari makan siang dan lemari makan, karena kita sedang berbicara tentang hal-hal yang hanya digunakan saat makan siang atau makan malam.
bbsimonbb

Jawaban:


38

Saya ingin mengatakan ini adalah pemrograman kultus kargo , tetapi ada alasan teknis untuk struktur ini. Asp.Net MVC mengambil konvensi atas pendekatan konfigurasi untuk hampir semua hal. Secara default, mesin tampilan Razor mencari Viewsdirektori untuk memutuskan tampilan mana yang akan kembali dari controller. Namun ada beberapa peretasan untuk mendapatkan struktur proyek yang berbeda dan Microsoft bahkan menyediakan fitur MVC yang disebut Area untuk memungkinkan kita membuat struktur proyek yang lebih waras. Anda juga dapat menerapkan mesin tampilan Anda sendiri untuk menentukan tempat mencari tampilan.

Mengapa saya mengatakan bahwa ini adalah pemrograman kultus kargo dan Anda benar tentang ini? Paman Bob meyakinkan saya bahwa struktur direktori proyek seharusnya tidak memberi tahu saya bahwa ini adalah aplikasi MVC. Seharusnya memberitahu saya bahwa itu adalah bagian depan toko, atau sistem permintaan cuti, atau apa pun. Struktur tingkat tinggi dan arsitektur harus memberitahu kami tentang apa hal ini, tidak bagaimana itu dilaksanakan.

Singkatnya, saya percaya Anda benar tentang hal ini, tetapi struktur direktori lainnya hanya akan berjuang melawan kerangka kerja dan percaya kepada saya ketika saya mengatakan bahwa Anda tidak ingin mencoba membuat kerangka kerja Asp.Net MVC melakukan sesuatu yang tidak dirancang untuk dilakukan. Sayang sekali bahwa itu tidak benar-benar dapat dikonfigurasi.


Untuk mengatasi masalah arsitektur dengan cepat, saya masih percaya bahwa model bisnis (bisnis, bukan tampilan) dan DAL harus hidup dalam proyek / perpustakaan terpisah yang dipanggil dari aplikasi MVC Anda.

Hanya saja pengontrolnya benar-benar sangat erat dengan tampilan dan kemungkinan akan dimodifikasi bersama. Kita semua bijaksana untuk mengingat perbedaan antara kopling melalui ketergantungan dan kopling logis. Hanya karena kode tersebut memiliki dependensi yang dipisahkan tidak membuatnya kurang digabungkan secara logis.


1
Cara komprehensif untuk mengendalikan di mana pisau cukur mencari pandangan ada di sini . Saya mungkin hanya bertahan.
bbsimonbb

3
Saya menyaksikan paman bob, pada x1.25 seperti yang disarankan. Itu membuat saya berpikir bahwa jika para arsitek IT membangun gedung, kita semua akan hidup dalam kelompok kecil rakit yang diikat bersama, melayang-layang di sekitar danau. Hidup tidak selalu lebih sederhana.
bbsimonbb

1
Itu menjadi sedikit lebih rumit. Untuk benar-benar menentukan lokasi pengontrol dan tampilan, Anda harus menyelesaikan jalur tampilan saat runtime, untuk menyertakan namespace pengontrol. Inilah cara melakukannya .
bbsimonbb

1
Lihat juga pengembangan perangkat lunak berorientasi fitur ( fosd.net ), untuk rekan akademis dengan apa yang Paman Bob uraikan.
ngm

1
Hukum Conway sedang bekerja. Saya yakin itu bekerja di @Flater perusahaan Anda. Tata letak MVC standar bekerja di banyak perusahaan, tetapi saya masih lebih suka mengelompokkan hal berdasarkan semantik di atas sintaks. Perusahaan tempat saya bekerja telah diorganisasikan di sekitar produk alih-alih fungsi / fungsi pekerjaan. Saya percaya ini adalah akar dari preferensi saya di sini.
RubberDuck

9

Apa pun alasannya, ini adalah praktik yang buruk. Ini sangat anti-OO karena paket atau folder (apa pun yang Anda ingin menyebutnya), harus memiliki saling ketergantungan yang lemah. Kelas (atau file) di dalamnya harus memiliki saling ketergantungan yang kuat.

Dengan melempar semua tampilan dalam satu folder dan semua controller di folder lain Anda membuat dua paket dengan kopling yang sangat ketat. Ini bertentangan dengan prinsip memiliki ketergantungan antar paket yang lemah.

Tampilan dan pengontrol adalah dua bagian dari keseluruhan dan harus saling memiliki. Anda tidak akan memiliki satu undian lemari untuk kaus kaki sisi kiri, dan satu lagi undian untuk kaus kaki kanan.


6

Untuk menjawab 'Kenapa semua orang ...?' pertanyaan: Berikut adalah beberapa alasan potensial, meskipun saya tidak sepenuhnya yakin kombinasi mana dari mereka yang merupakan penyebab sebenarnya, karena sebenarnya merupakan pertanyaan subjektif

  • Untuk mereplikasi arsitektur logis (model, tampilan, pengontrol) dengan folder yang sesuai dan struktur namespace

  • Keluar dari konvensi & kemudahan untuk mengikuti template proyek ASP.net MVC

  • Untuk mengelompokkan berdasarkan namespace, karena Controllers/folder akan mengarah ke .Controllersnamespace

  • Mungkin mengaktifkan beberapa skenario di DI / IoC di mana kelas pengontrol hanya ditanya / dipindai dari namespace yang berisi / diakhiri dengan 'Pengendali' (ini bisa salah)

  • Untuk memungkinkan Templat T4 memindai dan memodelkan perancah & pengontrol untuk menghasilkan tampilan

Anda selalu dapat membuat dan mengikuti konvensi Anda sendiri jika masuk akal untuk proyek Anda, tidak ada yang bisa / akan menghentikan Anda. Namun perlu diingat bahwa jika Anda bekerja di proyek besar dan / atau tim besar, maka konvensi default yang diketahui semua orang mungkin merupakan pilihan yang lebih baik (meskipun tidak harus yang benar!)

Jika konvensi Anda lebih mudah diikuti dan tidak menghalangi produktivitas, maka lakukanlah! dan mungkin bahkan menulis tentang itu satu atau dua posting blog untuk bersosialisasi dengan komunitas pengembang dan mendapatkan umpan balik


2

Salah satu alasan untuk menjaga pandangan dan pengontrol di direktori terpisah adalah ketika Anda memiliki pengembang front end dan back end mengerjakan sebuah proyek. Anda dapat mencegah pengembang ujung depan mengakses kode ujung belakang (misalnya untuk membantu kepatuhan PCI, membatasi siapa yang memiliki akses ke kode sensitif).

Alasan lain adalah untuk membuatnya lebih mudah untuk memiliki "tema" dan mengganti semua templat dengan membuat perubahan kecil ke jalur tampilan.

Alasan ketiga adalah memiliki pola direktori sederhana ketika menentukan tampilan dalam kerangka kerja MVC. Lebih mudah untuk menentukan sub-direktori dan file daripada jalur panjang yang besar untuk setiap tampilan.

Satu-satunya "kopling ketat" adalah:

  1. Variabel dikirim ke tampilan oleh pengontrol.
  2. Formulir bidang atau tindakan dalam tampilan, dikirim kembali ke pengontrol.

Saya menggunakan pengontrol generik dan mencoba untuk menjaga nama variabel dalam tampilan generik, sehingga banyak tampilan dapat menggunakan pengontrol yang sama, dan banyak pengontrol dapat menggunakan tampilan yang sama. Untuk alasan ini saya lebih suka untuk menjaga pandangan sepenuhnya terpisah. Model adalah tempat Anda dapat membedakan setiap "benda" dalam aplikasi Anda - mereka dapat berupa objek dengan daftar properti dan metode untuk mengakses / memodifikasi properti ini.

Untuk kode yang digabungkan secara ketat, pendekatan yang dapat bekerja untuk Anda adalah menjaga semua file yang merupakan bagian dari paket atau "modul" bersama-sama dalam direktori namespace. Kemudian Anda dapat menggunakan skrip untuk menyalin atau "kompilasi" templat mentah Anda ke direktori "tampilan" utama. Sebagai contoh:


    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1

Sayangnya, jika Anda ingin mengubah struktur tema yang sudah ada, ada lebih banyak tenun masuk dan keluar dari direktori paket untuk memperbarui tampilan.

Pertimbangkan bahwa tampilan hanyalah cara untuk memformat data, apakah itu json, xml, csv, atau html. Ini sangat membantu jika Anda ingin aplikasi Anda juga berfungsi sebagai API. Cobalah untuk memisahkan pandangan dari data, dengan menggunakan nama variabel generik, sehingga Anda dapat menggunakan templat yang sama untuk banyak pengontrol atau model (atau penggunaan termasuk untuk meminimalkan jumlah kode yang perlu Anda pertahankan).


1

Belum tentu semua orang melakukan ini. Misalnya kerangka Django python memiliki konsep aplikasi, di mana sub-modul aplikasi Anda tinggal di direktori mereka sendiri dengan model dan tampilan dan template mereka sendiri (tampilan adalah apa yang pada dasarnya Django sebut pengendali). Saya kebetulan lebih suka cara melakukan sesuatu karena itu berarti saya dapat dengan mudah mengemas "aplikasi" dan menggunakannya kembali di seluruh proyek hanya dengan memasukkannya ke dalam daftar aplikasi di pengaturan proyek saya. Juga lebih mudah untuk mengetahui di mana bagian-bagian yang berbeda berada. Jika saya melihat file urls.py dan melihat sesuatu seperti url(r'^users/', include('my_site.users.urls')), saya tahu bahwa modul my_site.usersberisi semua kode yang menangani pengguna. Saya tahu untuk melihat modul my_site.users.viewsdan my_site.users.modelsketika saya ingin melihat bagaimana pengguna dibuat dan diautentikasi. Saya tahu bahwa semua rute saya didefinisikan dalam my_site.users.url.

Juga jika cukup umum saya mungkin dapat menggunakan modul itu di situs lain hanya dengan mengubah konfigurasi atau mengemasnya sebagai pustaka dan menerbitkannya sebagai OSS.


1

Ingat itu adalah cara yang disarankan Microsoft untuk menjaga pengontrol dan tampilan di folder yang berbeda, sehingga banyak yang akan mengikuti struktur yang direkomendasikan,

  1. Salah satu alasannya adalah pengendali selalu tidak memiliki hubungan satu lawan satu dengan pandangan, terutama pandangan sebagian dapat dibagi di antara pengendali.
  2. Alasan lain bisa terjadi ketika proyek Anda tumbuh, Anda mungkin ingin menarik pengontrol dan menguji unit ke proyek lain, tetapi cukup sulit untuk melakukan hal yang sama untuk pandangan ditambah pandangan / js / css milik bersama saat mereka merujuk satu sama lain.

Setelah mengatakan bahwa ada banyak posting tentang melakukannya dengan cara Anda, seperti ini .


"Ini cara yang disarankan Microsoft" ... Bisakah Anda menjelaskan apa yang Anda maksud dengan itu? Apakah ada artikel MS aktual yang berwibawa tentang hal ini? Atau, apakah itu hanya pengaturan proyek default untuk aplikasi MVC? Dan, jika Anda mendasarkan ini pada yang terakhir, bukankah mungkin bahwa pengaturan proyek MVC default adalah apa itu karena bagaimana "semua orang" melakukannya ??
svidgen

1
Berdasarkan artikel msdn.microsoft.com/en-us/library/… ia mengatakan "Pengontrol, yang direkomendasikan" dan seterusnya untuk pandangan, dll.
Pelican Terbang Rendah

0

Untuk catatan

Mengapa saya mengatakan bahwa ini adalah pemrograman kultus kargo dan Anda benar tentang ini? Paman Bob meyakinkan saya bahwa struktur direktori proyek seharusnya tidak memberi tahu saya bahwa ini adalah aplikasi MVC. Seharusnya memberitahu saya bahwa itu adalah bagian depan toko, atau sistem permintaan cuti, atau apa pun. Struktur dan arsitektur tingkat tinggi harus memberi tahu kita tentang hal ini, bukan bagaimana penerapannya.

Pertanyaan: Siapa yang memiliki akses ke kode? Programmer. Apakah pengguna akhir peduli dengan kode ini? Tidak. Dan, apa yang dilakukan oleh seorang programmer, kode. Atau lebih khusus, kelas berdasarkan tipe (pengontrol, layanan, model, dan sebagainya). Jadi masuk akal dan mudah untuk men-debug kode, jika Anda dapat menemukan kode berdasarkan jenis kode, alih-alih dalam perilaku kode. Plus, katakanlah proyek tim, satu bertanggung jawab atas controller, satu lagi model, satu lagi dao dan satu lagi view. Sangat mudah untuk memisahkan proyek menjadi beberapa bagian. Kode yang baik adalah kode yang mudah di-debug, bukan kode gula sintaks. Paman Bob salah lagi.

Mencoba meniru perilaku proyek (bagian depan toko) adalah pemujaan kargo.


3
Ketika saya kode saya paling peduli tentang fitur, bukan tipe. Ketika saya melihat fitur yang tidak berfungsi seperti yang diharapkan, saya tahu ada sesuatu yang salah dalam kode yang terkait dengan fitur itu sementara saya tidak perlu tahu jenis kode itu.
Berhentilah melukai Monica

1
"Katakanlah proyek tim, satu bertanggung jawab atas controller, yang lain model, dan lain-lain dao" Tim semacam itu akan mengalami kesulitan pengiriman apa pun dan ketika mereka melakukannya akan ada biaya yang jauh lebih besar dalam overhead komunikasi dan bug.
RubberDuck

Seperti yang ditetapkan dalam rantai komentar di bawah jawaban yang diterima, Anda ada benarnya tetapi hanya dalam kasus tertentu. Ketika sebuah perusahaan berfokus pada proyek-proyek MVC yang dijualnya ke banyak klien yang beragam, mempertahankan struktur MVC masuk akal untuk dapat digunakan kembali. Ketika sebuah perusahaan berfokus pada ceruk (misalnya webshop) dan mungkin menggunakan banyak teknologi yang berbeda, lebih masuk akal untuk memiliki struktur yang berorientasi webshop. Ini adalah aplikasi praktis dari Hukum Conway . Kode (dan karenanya juga struktur proyek) harus mengikuti struktur perusahaan.
Flater

@RubberDuck: Anda dapat membuat argumen untuk biaya tambahan. Anda benar bahwa ketika orang yang berbeda melakukan komponen teknis yang berbeda, Anda telah meningkatkan komunikasi logika bisnis. Namun, jika Anda memiliki orang yang berbeda sepenuhnya menerapkan fitur yang berbeda, maka Anda mungkin telah meningkatkan biaya untuk memastikan semua orang di kapal (terampil + setuju) dengan menggunakan pendekatan teknis yang sama. Either way, Anda perlu overhead komunikasi untuk memastikan orang bekerja sama.
Flater

Ya dan handoffs selalu lebih mahal daripada memiliki satu devs yang menerapkan fitur ujung ke ujung IME.
RubberDuck
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.