Tôi có nên sử dụng DTO làm mô hình dữ liệu trong MVVM không?

Question

Tôi hiện đang làm việc về những gì sẽ là bước đột phá thực sự đầu tiên của tôi vào việc sử dụng MVVM và đã đọc nhiều bài viết về cách tốt nhất để thực hiện nó.

Suy nghĩ hiện tại của tôi là sử dụng các mô hình dữ liệu hiệu quả như các đối tượng chuyển dữ liệu, làm cho chúng có thể tuần tự hóa và tồn tại trên cả phía máy khách và máy chủ. Nó có vẻ giống như một bước hợp lý cho rằng cả hai loại đối tượng thực sự chỉ là bộ sưu tập của getters tài sản và setters và một lớp ở giữa có vẻ như overkill hoàn thành. Rõ ràng là sẽ có vấn đề với INotifyPropertyChanged không hoạt động chính xác ở phía máy chủ vì không có ViewModel để giao tiếp, nhưng miễn là chúng ta cẩn thận về việc xây dựng các đối tượng mô hình miền thích hợp từ mô hình dữ liệu trong lớp dịch vụ và không xử lý các mô hình dữ liệu ở phía máy chủ, tôi không nghĩ đó là vấn đề lớn.

Tôi không tìm thấy quá nhiều thông tin về cách tiếp cận này trong bài đọc của mình, vì vậy tôi muốn biết đây có phải là một điều khá chuẩn hay không, đây có phải là cách thực tế để thực hiện MVVM không tầng môi trường? Nếu tôi đã hoàn toàn sai ý tưởng về mọi thứ thì suy nghĩ về các cách tiếp cận khác cũng sẽ được đánh giá cao.

Answer 1

Tôi không có chuyên gia về vấn đề này. Tôi đã có cùng một kịch bản. Tôi đồng ý với bạn rằng điều đó khá là quá mức. Tôi đã sử dụng giải pháp này trong một thời gian và không gặp phải bất kỳ vấn đề nào. Các INotifyPropertyChanged không phải là một vấn đề lớn đối với tôi vì không có gì ở phía máy chủ sẽ đăng ký với sự kiện PropertyChanged. Nếu bạn sẽ sử dụng thừa kế trên các mô hình dữ liệu của bạn, thì tất cả đều phải được tuần tự hóa. Trong kịch bản của tôi, tôi có hai lớp cơ sở cho các mô hình dữ liệu của mình: một lớp được sử dụng để truyền dữ liệu và một lớp khác không được sử dụng.

Answer 2

Bạn có thể sử dụng bất kỳ mô hình nào bạn cảm thấy thoải mái, có tất cả các thuộc tính của bạn sẽ cần hành vi INotifyPropertyChanged. Làm thế nào điều này sẽ ảnh hưởng đến lớp dịch vụ hoàn toàn xuống đến thực hiện của bạn.

Tôi giả định rằng bạn cho rằng bạn ràng buộc với DTO trong chế độ xem của bạn?

Làm thế nào tôi thấy rằng có một sự không phù hợp trở kháng giữa các lớp của ứng dụng, đó là Mô hình miền của bạn có thể trông giống như mô hình quan hệ của bạn, với sự khác biệt tinh tế nhưng quan trọng. Ngoài ra còn có sự không khớp giữa Mô hình miền và DTO của bạn (đối tượng có thể được làm phẳng, tính chất được tính toán, v.v ...). Thật hấp dẫn để liên kết trực tiếp với DTO vì chúng có thể được thiết kế để có những gì bạn cần cho hoạt động cụ thể, tuy nhiên cũng có sự không phù hợp giữa DTO và những gì cần thiết cho khung nhìn để đạt được kết quả mong muốn. Mô hình khung nhìn có trách nhiệm ủy nhiệm các thuộc tính DTO cho khung nhìn, nó có trách nhiệm cho phép khung nhìn biết nếu có lỗi xác thực và các lệnh tuyến đến trình xử lý thích hợp (Lưu, Xóa, v.v. , ...).

Tôi có xu hướng thiết lập những điều theo cách sau:

// POCO object. Serializable. 
public class AddressDto 
{  
    public int Id { get; set; } 
    public string Street { get; set; }  
    public string City { get; set; }  
    public string Country { get; set; } 
} 

// IDataErrorInfo for validation. 
public class AddressViewModel : INotifyPropertyChanged, IDataErrorInfo 
{ 
    private readonly AddressDto addressDto; 

    public AddressViewModel(AddressDto addressDto) 
    { 
     this.addressDto = addressDto;  
    } 

    public int Id { /* get and set for property changed event and update dto */ } 
    public string Street { /* get and set for property changed event and update dto */ } 
    public string City { /* get and set for property changed event and update dto */ } 
    public string Country { /* get and set for property changed event and update dto */ } 
    ... 

    // IDataErrorInfo implementation 
} 

public class EditAddressViewModel : INotifyPropertyChanged 
{ 
    public AddressViewModel Address { /* get and set for property changed event */ } 
    public ICommand Save { /* setup command */ } 
    public ICommand Cancel { /* setup command */ } 

    private void Save() 
    { 
    } 

    private void Cancel() 
    { 
    } 
} 

EditAddressView của bạn sau đó sẽ liên kết với EditAddressViewModel. Về cơ bản, quy tắc là tất cả hành vi giao diện người dùng của bạn sẽ được thể hiện theo dạng xem của bạn.

Điều đó có nghĩa là thêm công việc, bạn có thể làm những việc bạn có thể làm để đơn giản hóa mọi thứ một chút (tạo mã v.v.). Tôi đang thực sự làm việc trên một thư viện nhằm mục đích đơn giản hóa toàn bộ quá trình MVVM bằng cách sử dụng một api thông thạo.Hãy khám phá tại số http://fluentviewmodel.codeplex.com/

Answer 3

Tôi quyết định có thuộc tính "Mô hình" trên ViewModel của mình. Trong chính mô hình, tôi đã thực hiện IPropertyNotifyChanged và IDataErrorInfo. Trong ViewModel của tôi, do đó tôi bỏ qua các thuộc tính trong đó mã sẽ đơn giản là "thông qua" cho mô hình. Thay vào đó, Chế độ xem liên kết trực tiếp với mô hình cho các thuộc tính đó.

Đối với các trường hợp phức tạp hơn, nơi tôi phải điều chỉnh dữ liệu trong mô hình để phù hợp với chế độ xem, tôi thực hiện việc này trong ViewModel. Ngoài ra, các lệnh, vv là trong ViewModel. Nhưng tôi không thấy lý do để có mã boilerplate trong ViewModel lặp đi lặp lại những thứ tương tự mà tôi đã có trong mô hình.