Apakah itu ide yang baik untuk menambahkan ViewModel persis sama dengan Model

Saya memiliki lapisan berikut dalam solusi saya:

1. App.Domain
2. Aplikasi. Layanan
3. App.Core (mungkin Anda menyebutnya App.DataLayer yang satu ini)
4. Aplikasi.Web

Pola desain perangkat lunak bukan pertanyaan saya, saya telah mengikuti Model di Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Saya ingin menggunakan model ini pada tampilan (misalnya beranda) DAN saya ingin menggunakan Id, Name & Value, jadi jika saya ingin membuat ViewModel, saya akan menambahkan yang berikut:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Jadi, apakah itu ide yang bagus? atau hanya gunakan Foosaja FooViewModel?

Ini mungkin terlihat seperti pelanggaran aturan KERING pada awalnya, tetapi saya berpendapat bahwa "kode yang serupa dan bahkan identik" tidak harus berarti "pengulangan" jika ia melakukan sesuatu yang berbeda atau dapat berubah secara independen. Dan dalam kasus model tampilan, kode mendefinisikan apa yang dilihat "klien", belum tentu entitas dan operasi yang dibicarakan bisnis. Jadi, Anda sering mengungkapkan model ke klien atau antarmuka yang agak "identik secara kebetulan." Anda dapat mengubah aturan dan ketentuan bisnis atau terminologi pengguna akhir secara independen satu sama lain.

Jadi, saya balikkan pertanyaannya pada Anda. Jika domain berubah, apakah klien "versi 1" dapat terus menggunakan antarmuka lama? Apakah Anda akan mengungkapkan istilah atau operasi di antarmuka yang bukan bagian dari "aturan bisnis inti?" Dan sebaliknya?

Pertanyaan-pertanyaan semacam itu ada dalam pikiran, jika "fungsi" tampilan Anda hanya untuk mengungkapkan model domain yang mendasarinya, ya, sepertinya ini melanggar aturan KERING.

_{Juga ingat, mengungkap pandangan bahwa perubahan lebih alami dengan perubahan model juga dapat dicapai dalam beberapa bahasa dengan atribut dan refleksi anggota. (Atau dengan pengulangan yang kurang melalui prestasi kepintaran lainnya ... Tapi, "kepintaran" sering gagal untuk membenarkan pengulangan yang membuat Anda terhindar.)}

Saya akan memiliki model tampilan yang berisi hanya satu properti, contoh Foo. Dengan begitu, Anda tidak melanggar KERING menurut definisi apa pun, jika Foo berubah, model tampilan Anda secara otomatis melihat perubahan, dan Anda membiarkan diri Anda bebas dari ikatan langsung model tampilan dengan model.

Jika besok ada kebutuhan untuk tampilan untuk menunjukkan sesuatu yang lain serta Foo, Anda bisa menambahkan properti baru, dan maksud model tampilan Anda akan tetap jelas, itu berisi Foo dan sesuatu yang lain, Anda tidak akan memiliki campuran properti dari Foo dengan properti lain yang tidak terkait.

Saya tidak akan menganggap model tampilan Anda sebagai FooViewModel, saya akan memikirkannya dalam hal tampilan yang seharusnya ditampilkan. Jika hanya menampilkan satu Foo, maka model tampilan berisi satu properti, Foo.

Tidak yakin apakah saya menjelaskannya dengan jelas. Jika tidak, beri tahu saya dan saya akan mencoba dan menulis ulang ketika saya bangun!

Saya akan mengatakan menggunakan FooViewModelcara ini melanggar prinsip KERING. Ketika Anda perlu melakukan perubahan, FooAnda juga harus melakukan perubahan FooViewModel. Saya pikir Anda akan lebih baik dilayani hanya menggunakan Foosebagai model untuk pandangan Anda. Saya akan mempertimbangkan model tampilan jika Anda perlu menampilkan sesuatu dari Foo dan sesuatu hal lainnya. Misalnya, Anda perlu merender beberapa informasi dari Foodan juga dari Bar.