MVVM là vô nghĩa? [đóng cửa]

Việc triển khai MVVM chính thống có vô nghĩa không? Tôi đang tạo một ứng dụng mới và tôi đã xem xét Windows Forms và WPF. Tôi đã chọn WPF vì nó phù hợp với tương lai và cung cấp nhiều tính linh hoạt. Có ít mã hơn và dễ dàng thực hiện các thay đổi quan trọng đối với giao diện người dùng của bạn bằng cách sử dụng XAML.

Vì sự lựa chọn cho WPF là hiển nhiên, tôi nghĩ rằng tôi cũng có thể sử dụng MVVM làm kiến ​​trúc ứng dụng của mình vì nó cung cấp khả năng hòa trộn, các mối quan tâm về phân tách và khả năng kiểm tra đơn vị. Về mặt lý thuyết, nó có vẻ đẹp giống như chén thánh của lập trình UI. Cuộc phiêu lưu ngắn ngủi này; tuy nhiên, đã trở thành một cơn đau đầu thực sự. Như mong đợi trong thực tế, tôi thấy rằng tôi đã đánh đổi một vấn đề này cho một vấn đề khác. Tôi có xu hướng trở thành một lập trình viên ám ảnh vì tôi muốn làm mọi thứ theo đúng cách để có thể đạt được kết quả phù hợp và có thể trở thành một lập trình viên giỏi hơn. Mô hình MVVM vừa làm thất bại bài kiểm tra của tôi về năng suất và vừa trở thành một vụ hack lớn của yucky!

Trường hợp rõ ràng ở điểm là thêm hỗ trợ cho hộp thoại Phương thức. Cách đúng là tạo một hộp thoại và gắn nó vào một mô hình khung nhìn. Làm cho điều này làm việc là khó khăn. Để hưởng lợi từ mẫu MVVM, bạn phải phân phối mã ở nhiều nơi trong suốt các lớp của ứng dụng của mình. Bạn cũng phải sử dụng các cấu trúc lập trình bí truyền như các mẫu và biểu thức lamba. Thứ khiến bạn cứ nhìn chằm chằm vào màn hình mà vò đầu bứt tai. Điều này làm cho việc bảo trì và gỡ lỗi trở thành cơn ác mộng chờ đợi xảy ra như tôi đã phát hiện gần đây. Tôi đã có một hộp giới thiệu hoạt động tốt cho đến khi tôi nhận được một ngoại lệ vào lần thứ hai tôi gọi nó, nói rằng nó không thể hiển thị lại hộp thoại sau khi nó bị đóng. Tôi đã phải thêm một trình xử lý sự kiện cho chức năng đóng vào cửa sổ hộp thoại, một cái khác trong triển khai IDialogView của nó và cuối cùng là một cái khác trong IDialogViewModel. Tôi đã nghĩ MVVM sẽ cứu chúng ta khỏi những vụ hack ngông cuồng như vậy!

Có một số người có các giải pháp cạnh tranh cho vấn đề này và tất cả đều là hack và không cung cấp một giải pháp thanh lịch, sạch sẽ, có thể tái sử dụng dễ dàng. Hầu hết các bộ công cụ MVVM phủ bóng trên các hộp thoại và khi chúng giải quyết chúng, chúng chỉ là các hộp cảnh báo không yêu cầu giao diện tùy chỉnh hoặc mô hình xem.

Tôi đang có ý định từ bỏ kiểu xem MVVM, ít nhất là cách triển khai chính thống của nó. Bạn nghĩ sao? Nó có đáng để bạn gặp rắc rối không? Tôi chỉ là một lập trình viên kém năng lực hay MVVM không phải là thứ mà nó được thổi phồng lên?

Xin lỗi nếu câu trả lời của tôi trở nên hơi dài dòng, nhưng đừng trách tôi! Câu hỏi của bạn cũng dài.

Tóm lại, MVVM không phải là vô nghĩa.

Trường hợp rõ ràng ở điểm là thêm hỗ trợ cho hộp thoại Phương thức. Cách đúng là tạo một hộp thoại và gắn nó vào một mô hình khung nhìn. Làm cho điều này làm việc là khó khăn.

Vâng, nó thực sự là như vậy.
Tuy nhiên, MVVM cung cấp cho bạn một cách để tách giao diện của UI khỏi logic của nó. Không ai ép bạn sử dụng nó ở mọi nơi, và không ai dí súng vào trán bạn để bắt bạn tạo một ViewModel riêng cho mọi thứ.

Đây là giải pháp của tôi cho ví dụ cụ thể này:
Cách giao diện người dùng xử lý một đầu vào nhất định không phải việc của ViewModel. Tôi sẽ thêm mã vào tệp .xaml.cs của View, tệp này khởi tạo hộp thoại và đặt cùng một phiên bản ViewModel (hoặc một cái gì đó khác, nếu cần) làm DataContext của nó.

Để hưởng lợi từ mẫu MVVM, bạn phải phân phối mã ở nhiều nơi trong suốt các lớp của ứng dụng của mình. Bạn cũng phải sử dụng các cấu trúc lập trình bí truyền như các mẫu và biểu thức lamba.

Chà, bạn không cần phải sử dụng nó ở nhiều nơi. Đây là cách tôi sẽ giải quyết nó:

• Thêm XAML vào Chế độ xem và không có gì trong .xaml.cs
• Viết mọi logic ứng dụng (ngoại trừ những thứ sẽ hoạt động trực tiếp với các phần tử giao diện người dùng) bên trong ViewModel
• Tất cả mã sẽ được thực hiện bởi giao diện người dùng nhưng không liên quan gì đến logic nghiệp vụ sẽ được chuyển vào tệp .xaml.cs

Tôi nghĩ rằng mục đích của MVVM chủ yếu là để tách biệt logic của ứng dụng và giao diện người dùng cụ thể, do đó cho phép dễ dàng sửa đổi (hoặc thay thế hoàn toàn) giao diện người dùng.
Tôi sử dụng nguyên tắc sau: View có thể biết và giả định bất cứ điều gì nó muốn từ ViewModel, nhưng ViewModel có thể biết KHÔNG GÌ về View.
WPF cung cấp một mô hình ràng buộc đẹp mà bạn có thể sử dụng để đạt được chính xác điều đó.

(BTW, các mẫu và biểu thức lambda không phải là bí truyền nếu được sử dụng đúng cách. Nhưng nếu bạn không muốn, đừng sử dụng chúng.)

Thứ khiến bạn cứ nhìn chằm chằm vào màn hình mà vò đầu bứt tai.

Vâng, tôi biết cảm giác. Chính xác là những gì tôi đã cảm thấy khi lần đầu tiên xem MVVM. Nhưng một khi bạn hiểu được nó, nó sẽ không còn cảm thấy tồi tệ nữa.

Tôi đã có một khoảng hộp hoạt động tốt ...

Tại sao bạn đặt ViewModel sau hộp giới thiệu? Không có ích lợi gì.

Hầu hết các bộ công cụ MVVM phủ bóng trên các hộp thoại và khi chúng giải quyết chúng, chúng chỉ là các hộp cảnh báo không yêu cầu giao diện tùy chỉnh hoặc mô hình xem.

Có, bởi vì thực tế là một phần tử giao diện người dùng nằm trong cùng một cửa sổ, hoặc một cửa sổ khác, hoặc đang quay quanh sao Hỏa vào lúc này không phải là mối quan tâm của ViewModels.
Tách các mối quan tâm

BIÊN TẬP:

Đây là một video rất hay có tiêu đề là Xây dựng khuôn khổ MVVM của riêng bạn . Nó đáng xem.

Làm cho điều này làm việc là khó khăn. Để hưởng lợi từ mẫu MVVM, bạn phải phân phối mã ở nhiều nơi trong suốt các lớp của ứng dụng của mình. Bạn cũng phải sử dụng các cấu trúc lập trình bí truyền như các mẫu và biểu thức lamba.

Đối với một hộp thoại phương thức phổ biến? Bạn chắc chắn đang làm sai ở đó - việc triển khai MVVM không cần phải phức tạp như vậy.

Xem xét bạn là người mới đối với cả MVVM và WPF, có khả năng bạn đang sử dụng các giải pháp không tối ưu ở mọi nơi và làm phức tạp mọi thứ một cách không cần thiết - ít nhất là tôi đã làm như vậy khi lần đầu tiên sử dụng WPF. Đảm bảo rằng vấn đề thực sự là MVVM chứ không phải do bạn triển khai trước khi từ bỏ.

MVVM, MVC, Document-View, v.v. là một họ các mẫu cũ .. Có những nhược điểm, nhưng không có sai sót nghiêm trọng nào thuộc loại như bạn mô tả.

Tôi đang ở giữa quá trình phát triển MVVM khá phức tạp bằng cách sử dụng PRISM nên tôi đã phải đối phó với loại lo lắng này.

Kết luận cá nhân của tôi:

MVVM so với MVC / PopUps & co

• MVVM thực sự là một mô hình tuyệt vời và trong hầu hết các trường hợp, nó thay thế hoàn toàn MVC nhờ liên kết dữ liệu mạnh mẽ trong WPF
• Gọi lớp dịch vụ của bạn trực tiếp từ trình bày là cách triển khai hợp pháp trong hầu hết các trường hợp
• Ngay cả các tình huống Danh sách / Chi tiết khá phức tạp cũng có thể được thực hiện bởi MVVM thuần túy nhờ vào cú pháp {Binding Path = /}
• Tuy nhiên, khi sự phối hợp phức tạp giữa nhiều chế độ xem cần được thực hiện, một bộ điều khiển bắt buộc
• Sự kiện có thể được sử dụng; mẫu cũ ngụ ý lưu trữ các phiên bản IView (hoặc AbstractObserver) trong bộ điều khiển đã lỗi thời
• Bộ điều khiển có thể được đưa vào mỗi Người trình bày bằng bộ chứa IOC
• Dịch vụ IEventAggregator của Prism là một giải pháp khả thi khác nếu việc sử dụng bộ điều khiển duy nhất là điều phối sự kiện (trong trường hợp này, nó có thể thay thế hoàn toàn bộ điều khiển)
• Nếu các khung nhìn được tạo động, đây là một công việc rất phù hợp cho bộ điều khiển (trong lăng kính, bộ điều khiển sẽ được đưa vào (IOC) một IRegionManager)
• Hộp thoại phương thức hầu hết đã lỗi thời trong các ứng dụng tổng hợp hiện đại, ngoại trừ các hoạt động thực sự chặn như xác nhận bắt buộc; trong những trường hợp này, kích hoạt phương thức có thể được trừu tượng hóa như một dịch vụ được gọi bên trong bộ điều khiển và được thực hiện bởi một lớp chuyên biệt, cũng cho phép kiểm tra đơn vị mức trình bày nâng cao. Ví dụ, bộ điều khiển sẽ gọi IConfirmationService.RequestConfirmation (“bạn có chắc không”) sẽ kích hoạt hiển thị hộp thoại phương thức trong thời gian chạy và có thể dễ dàng bị chế nhạo trong quá trình thử nghiệm đơn vị

Tôi đối phó với vấn đề hộp thoại bằng cách gian lận. MainWindow của tôi triển khai giao diện IWindowServices hiển thị tất cả các hộp thoại dành riêng cho ứng dụng. Sau đó, các ViewModels khác của tôi có thể nhập giao diện dịch vụ (tôi sử dụng MEF, nhưng bạn có thể dễ dàng chuyển giao diện qua các trình tạo theo cách thủ công) và sử dụng nó để thực hiện những gì cần thiết. Ví dụ, đây là giao diện của một ứng dụng tiện ích nhỏ của tôi:

//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
    bool ExecuteNewProject(NewProjectViewModel model);

    bool ExecuteImportSymbols(ImportSymbolsViewModel model);

    bool ExecuteOpenDialog(OpenFileDialog dialog);

    bool ExecuteSaveDialog(SaveFileDialog dialog);

    bool ExecuteWarningConfirmation(string text, string caption);

    void ExitApplication();
}

Điều này đặt tất cả các lần thực thi Hộp thoại vào một nơi và nó có thể dễ dàng phân chia để kiểm tra đơn vị. Tôi làm theo mẫu mà khách hàng của hộp thoại có để tạo ViewModel thích hợp, sau đó họ có thể định cấu hình nếu cần. Các khối lệnh gọi Thực thi và sau đó, khách hàng có thể xem nội dung của ViewModel để xem kết quả Hộp thoại.

Thiết kế MVVM 'tinh khiết' hơn có thể quan trọng đối với một ứng dụng lớn, nơi bạn cần cách nhiệt sạch hơn và thành phần phức tạp hơn, nhưng đối với các ứng dụng có kích thước vừa và nhỏ, tôi nghĩ rằng một cách tiếp cận thực tế, với các dịch vụ thích hợp để hiển thị các móc cần thiết, là khá đủ .

Mẫu thiết kế ở đó để giúp bạn, không cản trở. Một phần nhỏ để trở thành một nhà phát triển giỏi là biết khi nào nên "phá vỡ các quy tắc". Nếu MVVM cồng kềnh cho một nhiệm vụ và bạn đã xác định giá trị tương lai không đáng để nỗ lực, thì không sử dụng mẫu này. Ví dụ, như các áp phích khác đã nhận xét, tại sao bạn lại đi tất cả các chi phí để triển khai một hộp giới thiệu đơn giản?

Các mẫu thiết kế không bao giờ có ý định tuân theo một cách giáo điều.

Như bản thân mô hình MVVM là tuyệt vời. Nhưng thư viện điều khiển của WPF được vận chuyển với hỗ trợ ràng buộc dữ liệu NET 4.0 rất hạn chế, nó tốt hơn rất nhiều so với WinForm, nhưng nó vẫn chưa đủ cho MVVM có thể ràng buộc, tôi có thể nói rằng sức mạnh của nó là khoảng 30% những gì cần thiết cho MVVM có thể ràng buộc.
MVVM có thể liên kết: đó là giao diện người dùng mà ViewModel được kết nối với Chế độ xem chỉ sử dụng liên kết dữ liệu.
Mẫu MVVM là về biểu diễn đối tượng của ViewState, nó không mô tả cách bạn duy trì sự đồng bộ giữa View và ViewModel, trong WPF, nó là ràng buộc dữ liệu nhưng nó có thể là bất cứ thứ gì. Và trên thực tế, bạn có thể sử dụng mẫu MVVM trong bất kỳ bộ công cụ giao diện người dùng nào hỗ trợ sự kiện \ callbacks, bạn có thể sử dụng nó trong WinAPI thuần túy trong WinForms (tôi đã làm, và nó không hoạt động nhiều hơn với sự kiện \ callbacks) và thậm chí bạn có thể sử dụng nó trong Văn bản Bảng điều khiển, như viết lại Norton Commander của DoS bằng cách sử dụng mẫu MVVM.

Tóm lại: MVVM không phải là vô nghĩa, nó rất tuyệt. Thư viện điều khiển của NET 4.0 WPF là thùng rác.

Đây là bằng chứng đơn giản về khái niệm ViewModel mà bạn không thể liên kết dữ liệu theo cách MVVM thuần túy bằng cách sử dụng WPF.

public class PersonsViewModel
{
    public IList<Person> PersonList;
    public IList<ColumnDescription> TableColumns;
    public IList<Person> SelectedPersons;
    public Person ActivePerson;
    public ColumnDescription SortedColumn;
}

Bạn không thể liên kết dữ liệu các tiêu đề cột DataGrid của WPF, bạn không thể liên kết dữ liệu các hàng đã chọn, v.v., bạn sẽ làm điều đó theo cách mã đơn giản hoặc viết 200 dòng mã hack XAML cho 5 dòng ViewModel đơn giản nhất này. Bạn chỉ có thể tưởng tượng mọi thứ trở nên tồi tệ như thế nào với các ViewModels phức tạp.
Vì vậy, câu trả lời là đơn giản trừ khi bạn đang viết ứng dụng Hello World, việc sử dụng MVVM có thể ràng buộc trong WPF là vô nghĩa. Bạn sẽ dành phần lớn thời gian để suy nghĩ về việc hack để ràng buộc bạn ViewModel. Liên kết dữ liệu là tốt nhưng hãy sẵn sàng dự phòng cho 70% thời gian của sự kiện.

Không, không phải là vô nghĩa, nhưng rất khó để quấn quanh đầu bạn mặc dù bản thân họa tiết đơn giản đến kỳ lạ. Có rất nhiều thông tin sai lệch trên mạng và các nhóm khác nhau tranh nhau tìm cách thích hợp. Tôi nghĩ với WPF và Silverlight, bạn nên sử dụng MVVM nếu không bạn sẽ phải viết mã quá mức và cố gắng giải quyết các vấn đề trong một mô hình mới, phương pháp luận của các biểu mẫu win “cũ” chỉ khiến bạn gặp rắc rối. Đây là trường hợp nhiều hơn trong Silverlight vì mọi thứ bắt buộc phải không đồng bộ (có thể xảy ra hack xung quanh điều này, nhưng bạn chỉ nên chọn một nền tảng khác).

Tôi khuyên bạn nên đọc bài viết này Đơn giản hóa WPF TreeView bằng cách sử dụng ViewModel Pattern một cách cẩn thận để xem MVVM có thể được triển khai tốt như thế nào và cho phép bạn thay đổi tâm lý của win form sang cách suy nghĩ mới trong MVVM. Tóm lại, khi bạn muốn hoàn thành một việc gì đó, hãy áp dụng logic cho ViewModel trước tiên không phải là View. Bạn muốn chọn một mục? Thay đổi biểu tượng? Không lặp lại các phần tử giao diện người dùng, chỉ cần cập nhật các thuộc tính của mô hình và để việc ràng buộc dữ liệu thực hiện việc thực hiện nghiêm túc.

Tôi đã gặp vấn đề tương tự với rất nhiều triển khai MVVM khi nói đến hộp thoại (phương thức). Khi tôi nhìn những người tham gia Mô hình MVVM, tôi có cảm giác rằng còn thiếu một thứ gì đó để xây dựng một ứng dụng mạch lạc.

• Chế độ xem chứa các điều khiển GUI cụ thể và xác định giao diện của giao diện người dùng.
• ViewModel đại diện cho trạng thái và hành vi của bản trình bày.
• Mô hình có thể là một đối tượng nghiệp vụ từ lớp miền hoặc một dịch vụ cung cấp dữ liệu cần thiết.

Nhưng thiếu là:

• Ai tạo ViewModels?
• Ai chịu trách nhiệm về quy trình làm việc của ứng dụng?
• Ai là người trung gian giữa các ViewModels khi họ cần giao tiếp với nhau?

Cách tiếp cận của tôi là giới thiệu một Bộ điều khiển (Use-Case) chịu trách nhiệm cho những điểm còn thiếu. Cách hoạt động của điều này có thể được xem tại các ứng dụng mẫu WPF Application Framework (WAF) .