Haruskah Tampilan tidak melakukan validasi?

Saya sedang membaca " Dalam MVC haruskah model menangani validasi? " Karena saya ingin tahu tentang ke mana logika validasi harus dimasukkan dalam situs web MVC. Satu baris dalam jawaban teratas berbunyi seperti ini: "pengendali harus menangani validasi, model harus menangani verifikasi."

Saya suka itu, tetapi itu membuat saya bertanya-tanya mengapa kami tidak akan melakukan validasi data di View, karena beberapa alasan:

1. Tampilan biasanya memiliki dukungan validasi yang kuat (perpustakaan JS, tag HTML5)
2. Tampilan dapat divalidasi secara lokal, mengurangi IO jaringan
3. UI sudah dirancang dengan mempertimbangkan tipe data (kalender untuk tanggal, pemintal untuk angka), menjadikannya satu langkah kecil dari validasi

Memvalidasi di lebih dari satu tempat bertentangan dengan konsep MVC tentang tanggung jawab isolasi, sehingga "melakukannya di keduanya" tampaknya tidak tepat. Apakah melakukan validasi data hanya di controller benar-benar pendekatan yang dominan?

Saya tidak berpikir ada satu tempat di mana Anda dapat mengatakan semua validasi harus dilakukan. Ini karena kami memiliki beberapa strategi pemrograman bersaing yang berbeda yang bekerja bersama di situs web standar MVC asp.net.

Pertama kita memiliki ide untuk memisahkan logika domain menjadi model, logika 'aksi' menjadi pengontrol dan tampilan menjadi Tampilan. Ini didasarkan pada gagasan bahwa semua logika akan terjadi di server dengan browser hanya memberikan tampilan.

Kemudian, kami memperluas Tampilan dengan menggunakan javascript sisi klien. Ini sangat canggih akhir-akhir ini sehingga ide 'satu halaman situs web' dengan Jquery / knockout / angular adalah praktik umum.

Praktek ini dapat setara dengan menulis aplikasi sisi klien keseluruhan yang dengan sendirinya menerapkan pola MVC atau MVVM. Kami merendahkan Tampilan ke Objek Transfer Data dan Pengendali ke titik akhir layanan. Memindahkan semua logika bisnis dan UI ke klien.

Ini bisa memberikan pengalaman pengguna yang lebih baik, tetapi Anda harus memercayai klien yang pada dasarnya tidak bisa dipercaya. Jadi, Anda masih perlu melakukan logika validasi di server, terlepas dari seberapa baik klien Anda melakukan pra-validasi permintaannya.

Juga, kami sering memiliki persyaratan validasi yang tidak dapat dilakukan oleh klien. misalnya. 'Apakah ID baru saya unik?'

Aplikasi apa pun yang Anda buat dengan tujuan memberikan pengalaman / kinerja terbaik tentu akan meminjam untuk beberapa paradigma pemrograman dan membuat kompromi pada mereka untuk mencapai tujuannya.

Memvalidasi di lebih dari satu tempat bertentangan dengan konsep MVC tentang tanggung jawab isolasi, sehingga "melakukannya di keduanya" tampaknya tidak tepat.

Mungkinkah ada beberapa tanggung jawab validasi untuk dipertimbangkan di sini? Seperti yang Anda katakan di # 3 Anda:

UI sudah dirancang dengan mempertimbangkan tipe data (kalender untuk tanggal, pemintal untuk angka), menjadikannya satu langkah kecil dari validasi

Jadi mungkin itu:

Tampilan : Validasi jenis input, format, persyaratan ... validasi input pengguna dasar yang tidak ada hubungannya dengan logika bisnis. Tangkap semua barang lembut ini sebelum kami menghasilkan lalu lintas jaringan dengan membuat permintaan server.

Model : Validasi masalah bisnis data. Apakah itu nilai hukum menurut aturan bisnis? Ya, ini adalah nilai numerik (kami memastikannya dalam tampilan), tetapi apakah ini masuk akal?

Hanya pemikiran saja.

Saya akan menganggap Anda perlu validasi untuk kegigihan.

Tidak hanya Lihat, tetapi Model juga tidak boleh menangani validasi. Selama hari-hari saya di IT saya menyadari DDD adalah salah satu cara untuk memastikan Anda benar-benar melakukan sesuatu dengan benar, yaitu. kelas sebenarnya bertanggung jawab atas apa yang seharusnya.

Saat mengikuti desain Domain-Driven, model Anda menyertakan logika bisnis Anda, dan hanya itu. Tetapi mereka tidak memasukkan validasi, mengapa tidak?

Mari kita asumsikan Anda sudah sejauh yang Anda gunakan Data Mapperdaripada Active Recordbertahan lapisan domain Anda. Tapi tetap saja, Anda ingin model divalidasi, jadi Anda menambahkan validasi ke Model Anda.

interface Validation
{
    public function validate();
}

class ConcreteModel extends MyModel implements Validation
{
    public function validate() { // the validation logic goes here }
}

Logika validasi memastikan, Anda dapat memasukkan model dengan benar ke dalam basis data MySQL Anda ... Beberapa bulan berlalu dan Anda memutuskan, Anda ingin menyimpan Model Anda di basis data noSQL juga, basis data, yang memerlukan aturan validasi berbeda dari MySQL.

Tetapi Anda memiliki masalah, Anda hanya memiliki 1 metode validasi, tetapi perlu memvalidasi Modeldalam 2 cara berbeda.

Model harus melakukan apa yang mereka harus lakukan , mereka harus menjaga logika bisnis Anda dan melakukannya dengan baik. Validasi terkait dengan kegigihan, bukan logika bisnis, karenanya validasi bukan milik model .

Anda harus membuat Validators, yang akan mengambil model untuk memvalidasi dalam konstruktor mereka sebagai parameter, mengimplementasikan Validationantarmuka dan menggunakan ini Validatoruntuk memvalidasi objek Anda.

interface Validation
{
    public function validate();
}

class MySQLConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model here
    }
}

class RedisConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model with different set of rules here
    }
}

Jika suatu saat di masa depan memutuskan Anda ingin menambahkan metode validasi lain untuk lapisan kegigihan lainnya (karena Anda memutuskan Redis dan MySQL bukan cara untuk pergi lagi), Anda hanya akan membuat yang lain Validatordan menggunakan IoCwadah Anda untuk mendapatkan instance yang tepat berdasarkan pada Anda config.

Bagi banyak pengembang, model Fat melawan Pengendali Jelek Bodoh adalah metode yang disukai.

Konsep dasar dalam teks adalah

... Jadi selalu ingat bahwa Model bukan hanya basis data. Bahkan data yang Anda dapatkan dari layanan web dapat dinyatakan sebagai Model! Ya, bahkan feed Atom! Kerangka kerja yang mengeluarkan perkenalan Model, hampir tidak pernah menjelaskan dimuka ini yang hanya memperburuk kesalahpahaman.

dan

Tampilan seharusnya hanya mementingkan pembuatan dan penyajian UI sehingga pengguna dapat mengomunikasikan maksud ke Model . Pengontrol adalah orkestrator yang menerjemahkan input UI ke dalam tindakan pada Model dan meneruskan kembali output dari apa pun yang View telah ketahui tentang Model yang disajikannya. Pengontrol harus mendefinisikan perilaku aplikasi hanya dalam arti bahwa mereka memetakan input pengguna ke panggilan dalam Model, tetapi di luar peran itu harus jelas semua logika aplikasi lain yang terkandung dalam Model. Pengendali adalah makhluk rendahan dengan kode minimal yang hanya mengatur panggung dan membiarkan segala sesuatunya bekerja dengan cara yang teratur.

Tampilan seharusnya hanya mementingkan pembuatan dan penyajian UI sehingga pengguna dapat mengomunikasikan maksud ke Model adalah bagian penting. Model harus mendefinisikan data yang tersimpan, sehingga harus juga bertanggung jawab untuk memeriksa validitas data.

Saat mengambil catatan seseorang, setiap orang harus memiliki nomor ID unik yang diberikan oleh negara. Pemeriksaan ini (umumnya) dilakukan dengan UNIQUEpemeriksaan kunci oleh basis data. Setiap nomor ID yang diberikan harus memenuhi beberapa langkah kontrol (jumlah digit ganjil harus sama dengan jumlah digit genap dll). Jenis kontrol ini harus dilakukan olehModel

Pengontrol mengumpulkan data dari Modeldan meneruskannya ke View, atau membalikkan, mengumpulkan data pengguna melalui Viewdan meneruskannya ke Model. Setiap pembatasan dalam mengakses data dan memvalidasinya tidak boleh dilakukan oleh Controller. Itu Controlleryang mengumpulkan data cookie dan itu Modelyang memeriksa apakah itu sesi yang valid atau pengguna memiliki akses ke bagian aplikasi ini.

Viewadalah antarmuka pengguna yang mengumpulkan data dari pengguna atau menyajikan data ke pengguna. Pemeriksaan sederhana dapat dilakukan dengan Viewseperti memasukkan alamat email pengguna atau tidak (dengan demikian ini juga dapat dilakukan di View) IMO.

Lihat adalah sisi klien, dan Anda tidak boleh memasukkan input pengguna. Javascripts mungkin gagal berjalan di sisi klien, pengguna dapat menggunakan skrip tulisan tangan untuk mengubahnya atau menonaktifkan skrip menggunakan browser. Anda dapat mengatur skrip validasi sisi klien, tetapi jangan pernah Anda tidak boleh mendorongnya dan melakukan pemeriksaan nyata pada Modellayer.

Tampilan harus melakukan validasi untuk tujuan:

1. ) Validasi ujung depan dapat mengurangi lalu lintas data di server Anda.
2. ) itu menangani data yang tidak valid sebelum dapat melakukan perjalanan di server Anda.
3. ) jika Anda menginginkan keamanan yang lebih tinggi, kombinasi front end dan back end Validasi lebih baik.