Đó có phải là ý tưởng tốt để thêm ViewModel giống hệt như Model không

Tôi có các lớp sau trong giải pháp của mình:

1. Ứng dụng tên miền
2. Ứng dụng dịch vụ
3. App.Core (có thể bạn gọi đây là App.DataLayer)
4. Ứng dụng web

Mẫu thiết kế phần mềm không phải là câu hỏi của tôi, tôi đã theo Model trong Domain

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

Tôi muốn sử dụng mô hình này trên chế độ xem (ví dụ trang chủ) VÀ tôi muốn sử dụng Id, Name & Value, vì vậy nếu tôi muốn tạo ViewModel, tôi sẽ thêm vào như sau:

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

Vì vậy, đó là ý tưởng tốt? hoặc chỉ sử dụng Foothay vì FooViewModel?

Điều này có thể trông giống như vi phạm quy tắc DRY ban đầu, nhưng tôi cho rằng "mã tương tự và thậm chí giống hệt nhau" không nhất thiết là "sự lặp lại" nếu nó làm điều gì đó khác biệt hoặc có thể thay đổi độc lập. Và trong trường hợp mô hình khung nhìn, mã đang xác định những gì "khách hàng" nhìn thấy, không nhất thiết là các thực thể và hoạt động mà doanh nghiệp nói đến. Vì vậy, bạn thường tiết lộ các mô hình cho máy khách hoặc giao diện giống như "tình cờ giống hệt nhau". Bạn có thể thay đổi các quy tắc và điều khoản kinh doanh hoặc thuật ngữ người dùng cuối độc lập với nhau.

Vì vậy, tôi sẽ chuyển câu hỏi lại cho bạn. Nếu tên miền thay đổi, các máy khách "phiên bản 1" có thể chấp nhận tiếp tục sử dụng các giao diện cũ không? Bạn có bao giờ tiết lộ các điều khoản hoặc hoạt động trong giao diện không phải là một phần của "quy tắc kinh doanh cốt lõi không?" Và ngược lại?

Những loại câu hỏi trong đầu, nếu "chức năng" của chế độ xem của bạn hoàn toàn tiết lộ mô hình miền cơ bản, vâng, điều này có vẻ như nó vi phạm quy tắc DRY.

_{Cũng lưu ý, phơi bày một quan điểm thay đổi tự nhiên hơn với các thay đổi mô hình cũng có thể được thực hiện bằng một số ngôn ngữ có thuộc tính thành viên và sự phản chiếu. (Hoặc với sự lặp lại ít hơn thông qua các chiến công thông minh khác ... Nhưng, "sự thông minh" thường không thể biện minh cho sự lặp lại mà nó làm bạn thất vọng.)}

Tôi sẽ có một mô hình khung nhìn chỉ chứa một thuộc tính, một thể hiện Foo. Theo cách đó, bạn không vi phạm DRY theo bất kỳ định nghĩa nào về nó, nếu Foo thay đổi, mô hình khung nhìn của bạn sẽ tự động nhìn thấy sự thay đổi và bạn không bị ràng buộc trực tiếp của mô hình khung nhìn với mô hình.

Nếu ngày mai cần có chế độ xem để hiển thị một thứ khác cũng như Foo, bạn chỉ cần thêm một thuộc tính mới và ý định của mô hình xem của bạn sẽ vẫn rõ ràng, nó chứa Foo và một cái gì đó khác, bạn sẽ không có một hỗn hợp các thuộc tính từ Foo với các thuộc tính khác không liên quan.

Tôi sẽ không nghĩ về mô hình chế độ xem của bạn dưới dạng FooViewModel, tôi sẽ nghĩ về mô hình của chế độ xem được hiển thị. Nếu nó chỉ hiển thị một Foo, thì mô hình khung nhìn chứa một thuộc tính, một Foo.

Không chắc chắn nếu tôi giải thích rõ ràng. Nếu không, hãy cho tôi biết và tôi sẽ thử và điều chỉnh lại khi tôi thức!

Tôi sẽ nói sử dụng FooViewModeltheo cách này vi phạm hiệu trưởng DRY. Khi bạn cần thay đổi, Foobạn cũng phải thay đổi FooViewModel. Tôi nghĩ rằng bạn sẽ được phục vụ tốt hơn chỉ đơn giản là sử dụng Foolàm mô hình cho quan điểm của bạn. Tôi sẽ xem xét một mô hình xem nếu bạn cần hiển thị những thứ từ Foo và những thứ khác. Ví dụ, giả sử bạn cần hiển thị một số thông tin từ Foovà cũng từ Bar.