Ưu điểm và nhược điểm của việc có một chi tiết cụ thể WPF trong mô hình xem

Question

Tôi đang gặp rắc rối khi quyết định những gì để suy nghĩ về đoạn mã này:

public SolidColorBrush Brush 
{ 
    get { return IsValid ? _validItemBrush : _invalidItemBrush; } 
} 

Nó là một phần của một mô hình điểm trong dự án hiện tại của tôi và như bạn có thể tưởng tượng, các Brush sẽ bị ràng buộc với một số yếu tố văn bản trong giao diện người dùng, để chỉ ra (in-) hợp lệ của các phần dữ liệu khác, trong một hộp thoại khá đơn giản và đơn giản.

Những người ủng hộ đoạn mã này nói rằng vì chúng tôi đang sử dụng WPF, chúng tôi cũng có thể cho phép một số cấu trúc WPF đơn giản cụ thể trong mô hình khung nhìn.

Các đối thủ nói rằng điều này vi phạm Tách mối quan tâm, vì nó rõ ràng ra lệnh cho phong cách cần được quan tâm chỉ bởi chế độ xem.

Vui lòng chia sẻ đối số của bạn và nếu bạn không hài lòng với mã ở trên, vui lòng chia sẻ ý tưởng của bạn về các giải pháp thay thế. (Tôi đặc biệt quan tâm đến những gì bạn phải nói về việc sử dụng DataTemplate s).

Có thể có một giải pháp có thể được xem là thực tiễn tốt nhất?

Answer 1

Cá nhân, tôi sẽ có hai bàn chải được xác định trong XAML, và có các điều khiển sử dụng chúng chuyển đổi bàn chải (trong xaml) dựa trên tài sản IsValid. Điều này có thể được thực hiện rất dễ dàng với DataTriggers, hoặc thậm chí là một IValueConverter đơn - bộ chuyển đổi có thể mất 2 bàn chải và một boolean và trao đổi giữa chúng khá dễ dàng.

Điều này sẽ giữ logic trình bày kinh doanh trung lập - "Bàn chải" rất cụ thể cho một hình thức trình bày cụ thể và lựa chọn Chế độ xem thuần túy. Việc mã hóa chặt chẽ điều này vào ViewModel vi phạm nguyên tắc trách nhiệm duy nhất cũng như không phải là một mối quan tâm tách biệt rõ ràng.

Tôi rất muốn giữ điều này trong Chế độ xem và chuyển đổi dựa trên thuộc tính IsValid (bị ràng buộc) là ViewModel cụ thể.

Answer 2

Trong khi có những trường hợp tôi có thể sử dụng cấu trúc WPF trong mô hình khung nhìn, đây không phải là một trong số chúng. Đây là lý do:

• Khó thay đổi hơn. Nếu bạn định nghĩa các cọ vẽ làm tài nguyên và sử dụng chúng theo kiểu, việc thay đổi lược đồ màu của ứng dụng có thể đơn giản là tải một từ điển tài nguyên khác. Nếu bạn mã hóa các giá trị màu trong các kiểu xem của mình, bạn có rất nhiều thứ khác nhau cần thay đổi nếu người dùng cuối của bạn cần các màu khác nhau.

• Khó kiểm tra hơn. Nếu bạn muốn viết một bài kiểm tra đơn vị kiểm tra xem một thuộc tính có trả về brush bên phải hay không, bạn phải tạo một brush trong phép kiểm tra đơn vị của mình và so sánh các giá trị của hai, vì nó là kiểu tham chiếu.

• Trong nhiều trường hợp, thậm chí hầu hết các trường hợp, nó không làm cho mã đơn giản hoặc dễ bảo trì hơn. Bạn đang khá có khả năng đã được sử dụng một phong cách (giả sử rằng bạn đang giao tiếp với phong cách), vì họ làm cho chỉ là về tất cả mọi thứ trong WPF dễ dàng hơn. Ràng buộc IsValid để tô màu chỉ là việc thêm DataTrigger vào một kiểu. Đó là nơi mà bất cứ ai duy trì mã này sẽ mong đợi để tìm thấy nó.

Chắc chắn có lần khi tôi sử dụng WPF xây dựng theo mô hình điểm - ví dụ, từ lâu dừng lại tự hỏi nếu đó là vấn đề nếu một mô hình điểm tiếp xúc với một loại tài sản của Visibility. Lưu ý rằng không có mối quan tâm nào ở trên áp dụng cho trường hợp đó.

Answer 3

Trong trường hợp như bạn hoàn toàn thẩm mỹ, tôi sử dụng Trình kích hoạt hoặc Trình quản lý trạng thái trực quan để thay đổi màu sắc.

Đôi khi tôi sử dụng màu trong Mô hình chế độ xem của mình, nhưng chỉ khi phần của thông số phần mềm của tôi (ví dụ: màu của biểu đồ hiển thị CO2 của bệnh nhân phụ thuộc vào bản địa hóa). Trong trường hợp đó, tôi sử dụng thuộc tính Color struct bound, cho phép View sử dụng Color cho một SolidColorBrush, một GradientStop, hoặc bất cứ thứ gì nó muốn. Ban đầu tôi đã sử dụng một chuỗi trong định dạng #AARRGGBB để loại bỏ hoàn toàn sự phụ thuộc WPF nhưng các đồng nghiệp dày dạn kinh nghiệm của tôi không thích điều đó.