MVVM chuẩn

Question

người trong Silverlight posted rằng MVVM hiện đang thiếu tiêu chuẩn để mọi người đã sở hữu hương vị ..

Đó là lý do tôi và một vài chàng trai đến từ WPF Disciples đang tích cực thảo luận mà các yếu tố của MVVM rằng tất cả mọi người đồng ý. Tôi hoàn toàn hiểu rằng chúng tôi đã thực hiện mô hình theo nhiều cách khác nhau và chúng tôi trộn lẫn một số mẫu hoặc tạo mô hình riêng dựa trên nhu cầu của dự án hoặc giúp cuộc sống của các nhà phát triển dễ dàng hơn. . Hãy thảo luận về các quy tắc chuẩn của mẫu MVVM mà mọi người đều đồng ý. Tôi cũng đã đăng some of my thoughts here.

Tại sao MVVM?

• Testabiltiy (ViewModel là dễ dàng hơn để kiểm tra đơn vị so với code-behind hoặc sự kiện đang driven)
• rõ ràng tách giữa nhà thiết kế UX và phát triển
• Tăng “Blendability” của quan điểm của bạn
• mẫu không bao giờ cần phải được thay đổi để hỗ trợ thay đổi cho chế độ xem
• Chế độ xemMô hình hiếm khi cần được thay đổi để hỗ trợ thay đổi cho chế độ xem
• Không có mã trùng lặp để cập nhật lượt xem

Đỗ và Đừng trong Xem

• không được chứa bất kỳ logic mà bạn muốn kiểm tra: Như Glenn nói rằng MVVM không phải là mã đếm tập thể dục, chúng ta có thể viết mã trong mã -phía sau. Nhưng bạn không bao giờ nên viết bất kỳ logic nào mà bạn muốn kiểm tra. Ví dụ: Nếu người dùng chọn quốc gia thì bạn muốn hiển thị danh sách các tiểu bang hoặc thành phố trong chế độ xem của bạn. Đây là yêu cầu kinh doanh, do đó bạn nên có bài kiểm tra đơn vị để kiểm tra logic này. Vì vậy, bạn không nên viết nó ở phía sau.
• có thể là một điều khiển hoặc Mẫu dữ liệu
• Giữ chế độ xem đơn giản nhất có thể. : Chúng tôi vẫn có thể sử dụng Trình kích hoạt dữ liệu hoặc Trình chuyển đổi giá trị hoặc Trạng thái trực quan hoặc Hành vi trộn trong XAML một cách cẩn thận.
• sử dụng kèm theo tài sản nếu có điều gì là không bindable:

Đỗ và Đừng trong ViewModel

• nối giữa View và mẫu
• Giữ Xem Nhà nước, giá trị chuyển đổi (Bạn có thể tạo cấu trúc dữ liệu mà bạn muốn hiển thị trong ViewModel thay vì sử dụng ValueConverter Ví dụ: Bạn cần hiển thị Name thay vì First Name và Last name. Model của bạn có thể có First Name và Last Name nhưng bạn có thể tạo thuộc tính Name trong ViewModel.)
• Không tham khảo mạnh hay yếu (thông qua Interface) của Xem
• Hãy VM như kiểm chứng càng tốt (ví dụ như không có cuộc gọi đến lớp Singleton)
• Không kiểm soát liên quan Stuff trong VM (Bởi vì nếu bạn đang thay đổi quan điểm sau đó bạn cũng sẽ phải thay đổi VM.)

Mẫu

• có thể Data Model, DTO, POCO, proxy tự động tạo ra các lớp miền và giao diện người dùng mẫu dựa trên cách bạn muốn có sự tách biệt giữa dịch vụ tên miền và trình bày lớp
• Không có tham chiếu đến ViewModel

Bạn có đề xuất hoặc nhận xét gì về điều đó không?

Chúng tôi có một sự bất đồng trong nhóm của chúng tôi. Một số người nói rằng không có giao diện của View trong ViewModel. Nhưng một số người nói rằng nếu View Model có giao diện của View thì nó sẽ là mẫu MVP.

Một trong những chuyên gia MVVM của chúng tôi nói về MVVM Vs MVP

Xem => ViewModel

• MVVM quan điểm là ràng buộc trực tiếp đến ViewModel và nói chuyện với VM qua databinding
• Trong MVP, khung nhìn được gắn với một mô hình treo ngoài SupervisingController hoặc không bị ràng buộc ở tất cả (dạng xem thụ động).

ViewModel => Xem

MVVM

1. INPC/tài sản gắn
2. Sự kiện
3. Messages (tổ chức sự kiện Aggregator/Messenger/RX khuôn khổ)
4. Qua trung gian chẳng hạn như dịch vụ
5. Thông qua một giao diện
6. Thông qua các đại biểu (Xem các đại biểu chuyển cho máy ảo mà nó có thể sử dụng để gọi lại. Ví dụ VM có thể trưng ra một phương thức SetActions mà các cuộc gọi View truyền cho nó đại biểu.

MVP

Trong trường hợp MVP tiêu chuẩn là các cuộc đàm phán thuyết trình về quan điểm hoặc thông qua một giao diện, liên kết dữ liệu, hoặc thông qua các thuộc tính trong trường hợp xem thụ động. Với Passive Xem các thuộc tính không sử dụng databinding, thay vì xem getters thuộc tính và setters được sử dụng để trực tiếp thiết lập giá trị điều khiển.

Bạn nghĩ gì về ý tưởng đó?

Bạn có nghĩ ViewModel có giao diện Chế độ xem không?

Nếu bạn muốn thêm nhiều hơn thì bạn đều được chào đón thêm ... :)

Toàn bộ ý tưởng về bài đăng này là để có được sự hiểu biết cùng một MVVM pattern trong cộng đồng.

Answer 1

Tôi thích những gì bạn đã viết.Một trong những điều thực sự gây lỗi cho tôi là có rất nhiều người dường như có máy ảo của họ kết hợp chặt chẽ với chế độ xem của họ - nếu bạn đang làm điều này thì bạn cũng có thể làm việc cũ XAML + mọi thứ được chuyển vào mã phía sau.

Mẫu tôi sử dụng là một biến thể nhỏ trên MVVM (nhưng chủ yếu là giống nhau). Cá nhân tôi muốn có ViewModel của tôi trao cho View như một giao diện - nó giữ cho sự tách biệt rất sạch sẽ. Điều này có rất nhiều lợi ích khi làm nguyên mẫu, các yếu tố hình ảnh có thể được chuyển vào hoặc ra khỏi View với ít hoặc không có tác động trên ViewModel.

Answer 2

Tôi nghĩ rằng sự giao tiếp giữa View ViewModel thông qua databinding là điều khiến MVVM trở thành mô hình riêng của nó trái ngược với việc phân tách các mối quan tâm khác. Nó không phải là quá nhiều cho dù nó GOOD hoặc BAD cho vm để biết về xem thông qua giao diện, nhưng trong bối cảnh giao tiếp các mô hình đang được sử dụng nó không phải là MVVM.

Một số khó khăn trong việc duy trì và duy trì các tiêu chuẩn nằm trong những thiếu sót và phức tạp của WPF và Silverlight, thật đáng buồn. Tuy nhiên, khi có nhiều tiêu chuẩn hợp lệ, tôi sẽ đội chiếc mũ Martin Fowler của tôi và thêm vào phần "khi nào sử dụng nó".

Tiêu chuẩn của bạn có đề cập đến các mối quan tâm xuyên suốt như bản địa hóa không?

FWIW Tôi thích nội dung của những gì bạn đã viết và vui bạn đăng nó ở đây ...

Chúc mừng,
Berryl