Trong điều kiện nào là việc sử dụng MVVM phù hợp?

Model View View-Model được Microsoft phát triển để nhắm mục tiêu các nền tảng phát triển UI hỗ trợ lập trình hướng sự kiện, cụ thể là Windows Presentation Foundation (WPF) và Silverlight trên nền tảng .NET sử dụng ngôn ngữ XAML và .NET. Trong những năm kể từ đó, nhiều khung Javascript như Angular, Knockout và ExtJS đã áp dụng mô hình này.

Giống như hầu hết các mẫu phần mềm, MVVM có cách sử dụng phù hợp và lạm dụng. Trong điều kiện nào là việc sử dụng MVVM phù hợp? Khi nào nó không được khuyên?

MVVM được dự định sẽ được sử dụng khi cần có các tương tác phức tạp của người dùng sử dụng UI có độ trung thực cao (ví dụ WPF ).

MVVM được nhắm mục tiêu vào các nền tảng phát triển giao diện người dùng hiện đại (Windows Presentation Foundation, hoặc WPF và Silverlight), trong đó có một nhà phát triển trải nghiệm người dùng (UXi) có các yêu cầu khác với các nhà phát triển truyền thống hơn (ví dụ: hướng tới logic kinh doanh và phát triển cuối cùng). Mô hình Chế độ xem của MVVM về cơ bản là một công cụ chuyển đổi giá trị trên các steroid, có nghĩa là Mô hình Chế độ chịu trách nhiệm phơi bày các đối tượng dữ liệu từ Mô hình theo cách mà các đối tượng đó dễ dàng được quản lý và tiêu thụ. Về mặt này, Mô hình Chế độ xem là Mô hình nhiều hơn Chế độ xem và xử lý hầu hết nếu không phải tất cả logic hiển thị của Chế độ xem.

MVVM được thiết kế để sử dụng các chức năng cụ thể trong WPF để tạo điều kiện thuận lợi hơn cho việc phân tách phát triển lớp View khỏi phần còn lại của mẫu bằng cách loại bỏ hầu như tất cả các mã phía sau mã ra khỏi lớp View. Thay vì yêu cầu Nhà thiết kế tương tác viết mã View, họ có thể sử dụng ngôn ngữ đánh dấu WPF gốc XAML và tạo các ràng buộc với ViewModel, được viết và duy trì bởi các nhà phát triển ứng dụng. Sự phân tách vai trò này cho phép Nhà thiết kế tương tác tập trung vào nhu cầu UX thay vì lập trình hoặc logic kinh doanh, cho phép các lớp của ứng dụng được phát triển trong nhiều luồng công việc.

Đối với UI nơi không cần loại tương tác phong phú này, MVVM có thể quá mức cần thiết; MVP có thể là một lựa chọn tự nhiên hơn. Đối với các ứng dụng web, MVC là phù hợp hơn. Đối với các ứng dụng rất nhỏ sẽ không bao giờ phát triển lớn hơn (như các tiện ích Winforms nhỏ), mã phía sau là đủ.

Đôi khi MVVM có thể là một cái bẫy. Theo kinh nghiệm của tôi, nó ưu tiên các ứng dụng giống CRUD (biểu mẫu trên dữ liệu) so với các UI hướng theo nhiệm vụ hơn. Tôi không nói rằng nó ngụ ý kiến ​​trúc xấu cho tầng sau / các lớp khác trong ứng dụng nhưng tôi đã thấy rất nhiều ứng dụng MVVM đi kèm với kiến ​​trúc "ánh sáng DDD". Tôi không biết tại sao chính xác có thể vì liên kết rất dễ dàng và rất đơn giản để thiết lập một ứng dụng với ORM và MVVM / Binding sử dụng các đối tượng miền POCO / Anemia.

MVVM là một hỗ trợ băng tần cho các lớp liên kết dữ liệu được thiết kế kém. Đặc biệt, nó đã được sử dụng rất nhiều trong thế giới WPF / silverlight / WP7 vì những hạn chế trong liên kết dữ liệu trong WPF / XAML.

Từ giờ trở đi, tôi sẽ cho rằng chúng ta đang nói về WPF / XAML vì điều này sẽ làm cho mọi thứ rõ ràng hơn. Hãy xem xét một số thiếu sót mà MVVM đặt ra để giải quyết trong WPF / XAML.

Hình dạng dữ liệu so với hình dạng UI

'VM' trong MVVM tạo ra một tập hợp các đối tượng được xác định trong C # ánh xạ vào một tập hợp các đối tượng trình bày được xác định trong XAML. Các đối tượng C # này thường được kết nối với XAML thông qua các thuộc tính DataContext trên các đối tượng trình bày.

Do đó, biểu đồ đối tượng viewmodel cần ánh xạ lên biểu đồ đối tượng trình bày của ứng dụng của bạn. Điều đó không có nghĩa là ánh xạ cần phải là một đối một, nhưng nếu điều khiển danh sách được chứa bởi điều khiển cửa sổ, thì phải có cách lấy từ đối tượng DataContext của cửa sổ đến một đối tượng mô tả dữ liệu của danh sách đó.

Biểu đồ đối tượng viewmodel tách riêng biểu đồ đối tượng mô hình khỏi biểu đồ đối tượng ui thành công, nhưng với chi phí của một lớp viewmodel bổ sung phải được xây dựng và duy trì.

Nếu tôi muốn chuyển một số dữ liệu từ màn hình A sang màn hình B, tôi cần phải loay hoay với chế độ xem. Trong suy nghĩ của một anh chàng kinh doanh, đây là một sự thay đổi UI. Nó sẽ diễn ra hoàn toàn trong thế giới của XAML. Đáng buồn thay, nó hiếm khi có thể. Tồi tệ hơn, tùy thuộc vào cách cấu trúc các khung nhìn và cách dữ liệu thay đổi tích cực, khá nhiều định tuyến lại dữ liệu có thể được yêu cầu để thực hiện thay đổi này.

Làm việc xung quanh ràng buộc dữ liệu không ấn tượng

Các ràng buộc WPF / XAML không đủ biểu cảm. Về cơ bản, bạn có thể cung cấp một cách để đến một đối tượng, một đường dẫn thuộc tính để đi qua và các trình biến đổi ràng buộc để điều chỉnh giá trị của thuộc tính dữ liệu với những gì đối tượng trình bày yêu cầu.

Nếu bạn cần liên kết một thuộc tính trong C # với bất kỳ thứ gì phức tạp hơn thế, thì về cơ bản bạn đã hết may mắn. Tôi chưa bao giờ thấy một ứng dụng WPF mà không có trình chuyển đổi ràng buộc biến thành đúng / sai thành Hiển thị / Thu gọn. Nhiều ứng dụng WPF cũng có xu hướng có một cái gì đó gọi là NegatingVisibilityConverter hoặc tương tự làm đảo lộn sự phân cực. Điều này nên được đặt ra chuông báo động.

MVVM cung cấp cho bạn các hướng dẫn để cấu trúc mã C # của bạn có thể được sử dụng để vượt qua giới hạn này. Bạn có thể hiển thị một thuộc tính trên chế độ xem của mình được gọi là someButtonVisibility và chỉ cần liên kết nó với khả năng hiển thị của nút đó. XAML của bạn bây giờ rất đẹp và đẹp ... nhưng bạn đã biến mình thành một nhân viên bán hàng - bây giờ bạn phải phơi bày + cập nhật các ràng buộc ở hai nơi (UI và mã trong C #) khi UI của bạn phát triển. Nếu bạn cần cùng một nút trên một màn hình khác, bạn đã phải phơi bày một thuộc tính tương tự trên chế độ xem mà màn hình đó có thể truy cập. Tệ hơn nữa, tôi không thể chỉ nhìn vào XAML và xem khi nào nút này sẽ hiển thị nữa. Ngay khi các ràng buộc trở nên hơi không cần thiết, tôi phải làm công việc thám tử trong mã C #.

Truy cập dữ liệu được tích cực trong phạm vi

Vì dữ liệu thường xâm nhập vào giao diện người dùng thông qua các thuộc tính DataContext, thật khó để thể hiện dữ liệu toàn cầu hoặc phiên trong toàn bộ ứng dụng của bạn.

Ý tưởng về "người dùng hiện đang đăng nhập" là một ví dụ tuyệt vời - đây thường là một điều thực sự toàn cầu trong một phiên bản của ứng dụng của bạn. Trong WPF / XAML, rất khó để đảm bảo quyền truy cập toàn cầu vào người dùng hiện tại một cách nhất quán.

Những gì tôi muốn làm là sử dụng từ "CurrentUser" trong các ràng buộc dữ liệu một cách tự do để chỉ người dùng hiện đang đăng nhập. Thay vào đó, tôi phải đảm bảo rằng mọi DataContext cung cấp cho tôi một cách để đến đối tượng người dùng hiện tại. MVVM có thể chứa được điều này, nhưng các khung nhìn sẽ trở nên lộn xộn vì tất cả chúng đều phải cung cấp quyền truy cập vào dữ liệu toàn cầu này.

Một ví dụ khi MVVM rơi xuống

Nói rằng chúng tôi có một danh sách người dùng. Bên cạnh mỗi người dùng, chúng tôi muốn hiển thị nút "xóa người dùng", nhưng chỉ khi người dùng hiện đang đăng nhập là quản trị viên. Ngoài ra, người dùng không được phép tự xóa.

Các đối tượng mô hình của bạn không nên biết về người dùng hiện đang đăng nhập - họ sẽ chỉ đại diện cho hồ sơ người dùng trong cơ sở dữ liệu của bạn, nhưng bằng cách nào đó, người dùng hiện đang đăng nhập cần phải tiếp xúc với các ràng buộc dữ liệu trong các hàng danh sách của bạn. MVVM ra lệnh rằng chúng ta nên tạo một đối tượng viewmodel cho mỗi hàng danh sách bao gồm người dùng hiện đang đăng nhập với người dùng được đại diện bởi hàng danh sách đó, sau đó hiển thị một thuộc tính có tên là "DeleteButtonVisibility" hoặc "CanDelete" trên đối tượng viewmodel đó (tùy thuộc vào cảm xúc của bạn về bộ chuyển đổi ràng buộc).

Đối tượng này sẽ trông rất giống một đối tượng Người dùng theo hầu hết các cách khác - nó có thể cần phải phản ánh tất cả các thuộc tính của đối tượng mô hình người dùng và chuyển tiếp cập nhật cho dữ liệu đó khi nó thay đổi. Cảm giác này thực sự tuyệt vời - một lần nữa, MVVM khiến bạn trở thành một nhân viên bán hàng bằng cách buộc bạn phải duy trì đối tượng giống người dùng này.

Xem xét - có lẽ bạn cũng phải thể hiện các thuộc tính của người dùng trong cơ sở dữ liệu, mô hình và chế độ xem. Nếu bạn có API giữa bạn và cơ sở dữ liệu của bạn, thì điều đó còn tệ hơn - chúng được thể hiện trong cơ sở dữ liệu, máy chủ API, ứng dụng khách API, mô hình và chế độ xem. Tôi thực sự do dự khi áp dụng một mẫu thiết kế đã thêm một lớp khác cần được chạm vào mỗi khi một thuộc tính được thêm hoặc thay đổi.

Thậm chí tệ hơn, lớp này chia tỷ lệ với độ phức tạp của giao diện người dùng của bạn, chứ không phải với độ phức tạp của mô hình dữ liệu của bạn. Thường thì cùng một dữ liệu được thể hiện ở nhiều nơi và trong giao diện người dùng của bạn - điều này không chỉ thêm một lớp, nó thêm lớp với nhiều diện tích bề mặt thêm!

Làm thế nào mọi thứ có thể đã được

Trong trường hợp được mô tả ở trên, tôi muốn nói:

<Button Visibility="{CurrentUser.IsAdmin && CurrentUser.Id != Id}" ... />

Hiện tại Người dùng sẽ được tiếp xúc trên toàn cầu với tất cả XAML trong ứng dụng của tôi. Id sẽ đề cập đến một thuộc tính trên DataContext cho hàng danh sách của tôi. Tầm nhìn sẽ tự động chuyển đổi từ boolean. Mọi cập nhật cho Id, CurrentUser.IsAdmin, CurrentUser hoặc CurrentUser.Id sẽ kích hoạt cập nhật cho khả năng hiển thị của nút này. Dễ như ăn bánh.

Thay vào đó, WPF / XAML buộc người dùng của mình tạo ra một mớ hỗn độn. Theo như tôi có thể nói, một số blogger sáng tạo đã tát một tên vào mớ hỗn độn đó và tên đó là MVVM. Đừng để bị lừa - nó không cùng lớp với các mẫu thiết kế của GoF. Đây là một hack xấu xí để làm việc xung quanh một hệ thống ràng buộc dữ liệu xấu xí.

(Cách tiếp cận này đôi khi được gọi là "Lập trình phản ứng chức năng" trong trường hợp bạn đang tìm đọc thêm).

Túm cái vạy lại là

Nếu bạn phải làm việc trong WPF / XAML, tôi vẫn không đề xuất MVVM.

Bạn muốn mã của mình được cấu trúc như ví dụ "cách mọi thứ có thể xảy ra" ở trên sẽ có nó - mô hình được hiển thị trực tiếp để xem, với các biểu thức liên kết dữ liệu phức tạp + các giá trị linh hoạt. Đó là cách tốt hơn - dễ đọc hơn, dễ ghi hơn và dễ bảo trì hơn.

MVVM cho bạn biết cấu trúc mã của bạn theo cách dài dòng hơn, ít bảo trì hơn.

Thay vì MVVM, hãy xây dựng một số nội dung để giúp bạn ước tính trải nghiệm tốt: Phát triển một quy ước để hiển thị trạng thái toàn cầu cho UI của bạn một cách nhất quán. Xây dựng cho mình một số công cụ từ các bộ chuyển đổi liên kết, MultiBinding, vv cho phép bạn thể hiện các biểu thức ràng buộc phức tạp hơn. Xây dựng cho mình một thư viện các bộ chuyển đổi ràng buộc để giúp các trường hợp cưỡng chế thông thường bớt đau đớn.

Thậm chí tốt hơn - thay thế XAML bằng một cái gì đó biểu cảm hơn. XAML là một định dạng XML rất đơn giản để khởi tạo các đối tượng C # - sẽ không khó để đưa ra một biến thể biểu cảm hơn.

Đề nghị khác của tôi: không sử dụng bộ công cụ buộc các loại thỏa hiệp này. Chúng sẽ làm tổn hại đến chất lượng sản phẩm cuối cùng của bạn bằng cách đẩy bạn về phía crap như MVVM thay vì tập trung vào miền vấn đề của bạn.

Tôi thực sự thích MVVM và tôi thấy những thách thức của nó thúc đẩy và thấy nhiều lợi ích, nhưng ...

1. Đối với ứng dụng hoặc trò chơi yêu cầu nhiều mã UI / tương tác để thêm nhiều hành vi tùy chỉnh trong khi duy trì sự hoàn hảo - tốt hơn là sử dụng MVVM hơi bẩn - sử dụng nó khi nó hữu ích hoặc trong trung tâm dữ liệu hơn so với khu vực trung tâm tương tác của mã. Giả sử bạn muốn tạo một điều khiển và di chuyển nó giữa các điều khiển cha khác nhau hoặc nếu không thì lưu trữ nó ...

2. Nó có một đường cong học tập khá dốc, vì vậy trừ khi bạn có thời gian, dự định phát triển rất nhiều về WPF / SL, có các nhà thiết kế có kỹ năng Blend, cảm thấy cần phải viết mã kiểm tra cho giao diện người dùng của bạn hoặc nếu không bạn sẽ phải bảo trì nhiều năm cho bạn dự án - nó có thể không trả hết.

3. Không nhiều nhà thiết kế biết Blend, không phải tất cả các dự án đều đáng tập trung vào kiểm tra tự động trên lớp trình bày, vì dù sao nó cũng cần phải được kiểm tra bằng tay và đó là cách bạn sẽ tìm thấy hầu hết các lỗi quan trọng, không phải bằng cách kiểm tra máy ảo của bạn.

4. Nó thực sự là một khoản đầu tư. Trước tiên, bạn phải nắm được các kiến ​​thức cơ bản về WPF / SL và XAML, sau đó tìm ra các cách để thực hiện các ràng buộc đúng, nối với vms theo một số thứ tự, nhận lệnh của bạn, chọn một khung trong hầu hết các trường hợp có thể gặp vấn đề do cấp phép, xây dựng thư viện sippets để mã hóa hiệu quả, chỉ để thấy rằng nền tảng không phải lúc nào cũng hoạt động tốt với các ràng buộc và cần xây dựng một thư viện các hành vi giúp bạn có được những gì bạn cần.

Nhìn chung - nếu bạn vượt qua tất cả các rào cản và trở nên khá thành thạo trong mô hình - tất cả sẽ trả lại sự rõ ràng, khả năng duy trì và ... Quyền khoe khoang? :)

Tôi đã là một lập trình viên WPF / Silverlight trong nhiều năm xây dựng các ứng dụng lớn, chẳng hạn như các hệ thống giao dịch, trên MVVM.

Đối với tôi, khi nhiều năm trôi qua, tôi đã học được rằng MVVM nghiêm ngặt ăn thời gian và tốn tiền. Theo nghiêm ngặt, tôi có nghĩa là các quy tắc như "không có mã phía sau".

Không thể trong bất cứ điều gì ngoại trừ ứng dụng biểu mẫu / cơ sở dữ liệu cơ bản nhất, không có mã phía sau.

Nhà thiết kế của bạn sẽ chỉ định một cái gì đó vào ngày đầu tiên không thể thực hiện được với các điều khiển tiêu chuẩn, vì vậy bạn phải xây dựng một loạt các điều khiển tùy chỉnh hoặc bọc các điều khiển hiện có, để hỗ trợ mô hình tương tác trong khi làm việc với MVVM.

Tôi đã viết tất cả các loại điều khiển UI swish bằng toán học, quán tính, cử chỉ, v.v. và công việc khó khăn của nó.

Nhưng đây là tất cả các mã phía sau, nó chỉ không nằm trong tầm nhìn. Bạn phải xử lý các lần nhấp nút, cuộn, kéo, v.v. nhưng tất cả được gói gọn trong một bộ điều khiển, điều này bằng cách nào đó làm cho mã phía sau này ổn.

Nó thường dễ dàng hơn chỉ đơn giản là viết mã phía sau và các công cụ UI thông minh trong chế độ xem, thay vì xây dựng một bộ điều khiển chỉ vì lợi ích của nó.

Mục tiêu của MVVM là tách logic ứng dụng / nghiệp vụ khỏi logic UI. Hệ thống ràng buộc và MVVM là một cách hay để làm điều này.

Các mục tiêu khác được mời chào, chẳng hạn như nhà thiết kế XAML trên một bàn, lập trình viên C # khác, một người làm việc trong Blend khác trong VS, là một ngụy biện.

Có thể nhanh chóng thiết kế lại UI là một sai lầm khác. Nó không bao giờ xảy ra, tối ưu hóa sớm của nó; bất kỳ công việc chính nào cũng cần rất nhiều công việc để làm cho các mô hình xem. Tinh chỉnh là một điều nhưng đại tu UI nhanh chóng là không thể; các mô hình khung nhìn phải phù hợp với mô hình tương tác, do đó khớp nối chặt chẽ hơn bạn có thể nhận ra.

Đối với tôi, tôi sử dụng MVVM để tách riêng logic ứng dụng của mình (tôi thường sử dụng bộ điều khiển có thể kiểm tra và một bộ mô hình khung nhìn logic) nhưng bất kỳ mã và thủ thuật nào là cần thiết để làm cho giao diện người dùng của tôi nhìn và hành động theo cách gợi cảm, tôi không đổ mồ hôi

Khác, cuối cùng bạn sẽ thống trị - trong các thiết kế của bạn, hoạt hình thú vị, v.v. chỉ vì ý tưởng về cách MVVM-arize tất cả trở nên quá khó hiểu.

MVVM, giống như hầu hết mọi thứ trong cuộc sống, có ở đâu đó điểm nhạy cảm giữa hai thái cực.

Điều quan trọng nhất trong thiết kế phần mềm là vận chuyển sản phẩm của bạn sớm, tìm hiểu các tính năng được sử dụng, giao diện người dùng nào hoạt động tốt và không viết mã đẹp cho sản phẩm không ai sử dụng.

Nếu ứng dụng của bạn yêu cầu bạn liên kết với lượng dữ liệu quá mức trong thời gian thực, thì MVVM thực sự có thể gây cản trở vì nó giới thiệu các tóm tắt làm chậm quá trình và giả sử chúng ta đang nói về WPF / Silverlight / WP7 ngay bây giờ, ràng buộc động cơ hiện không hiệu quả; mặc dù các cải tiến đang trên đường

MVVM, vì nó đứng, cũng không phải là phần duy nhất của phương trình bạn cần xem xét. MVVM thuần túy cần được hỗ trợ với cơ sở hạ tầng, chẳng hạn như mẫu Người hòa giải để cho phép bạn giao tiếp qua các ViewModels bị ngắt kết nối.

Bất chấp ý kiến ​​của blucz ở trên, MVVM nằm trong dòng các mẫu của GoF. Nếu bạn xem các mẫu, MVVM tương đương với mẫu Trình bày thụ động Model View, xuất hiện gần như cùng lúc với MVVM. Bạn sẽ thường xuyên ở đây mọi người phàn nàn về sự phức tạp của MVVM hoàn toàn vì họ không hiểu cách thiết kế bằng cách sử dụng nó.

Một lĩnh vực khác mà tôi đã tìm thấy vấn đề với MVVM là nơi bạn cần kết hợp công nghệ của bên thứ ba không được thiết kế để hỗ trợ nó (chẳng hạn như khung UII cho MS Dynamics). Đôi khi bạn phải tự hỏi liệu có đáng để "hack" xung quanh công nghệ khác chỉ để làm việc với MVVM hay không.

Nếu bạn đang trộn và kết hợp một cái gì đó như Win Forms vào giải pháp WPF của bạn, thì phần đó của giải pháp có lẽ cũng sẽ không phù hợp với MVVM. Tôi hy vọng điều này cung cấp cho bạn một số ý tưởng về một số lĩnh vực mà MVVM không áp dụng được.

Sử dụng MVVM không có nghĩa gì khi:

• Bạn không làm việc với WPF hoặc Silverlight
• Bạn đang thử nghiệm một khái niệm

Đó là nó. Tôi thực sự không thể nghĩ tại sao bạn KHÔNG sử dụng MVVM khi làm việc với WPF / Silverlight, trừ khi bạn đang thử nghiệm hoặc gỡ lỗi một cái gì đó trong một dự án riêng biệt. Tôi thấy mẫu thiết kế lý tưởng cho sự phát triển WPF / Silverlight vì cách thức hoạt động của XAML Bindings.

Điểm chung của MVVM là toàn bộ ứng dụng của bạn được chạy trong ViewModels và Chế độ xem của bạn chỉ đơn giản là một lớp đẹp mà người dùng có thể sử dụng để tương tác với ViewModels của bạn. Bạn muốn nhấp vào một nút, bạn thực sự đang chạy một phương thức ViewModel. Bạn muốn thay đổi trang, bạn thực sự đang thay đổi thuộc tính CurrentPage trong ViewModel.

Tôi sử dụng MVVM cho tất cả các phát triển WPF / Silverlight, ngay cả các dự án đơn trang nhỏ, đơn giản, mặc dù cách tôi sử dụng MVVM khác nhau dựa trên quy mô của dự án và những gì tôi cần. Một lần tôi đã làm một ứng dụng nhỏ mà không có MVVM, cuối cùng tôi đã hối hận (sau đó nó đã được tái cấu trúc để sử dụng MVVM trong khi thêm một bản cập nhật)

Tôi đã thực hiện một số công việc cho một khách hàng trong một dự án bị mã hóa phía sau với nỗ lực chuyển đổi sang MVVM được đưa vào và đó là một mớ hỗn độn khổng lồ. Điều đó không có nghĩa là tất cả các dự án mã phía sau là một mớ hỗn độn. Các khung nhìn sẽ bị lỗi hoặc sụp đổ Blend gây ra sự cố cho các nhà thiết kế.

Tôi đã tìm hiểu về RoR và đã bỏ qua khá nhiều việc với ASP.NET Webforms nhưng khi ASP.NET MVC xuất hiện, tôi đã cố gắng học nhiều nhất có thể, thường sử dụng sách ASP.NET MVC In Action và codecamperver làm tài liệu tham khảo . Mặc dù đó là một mô hình khác, tôi sử dụng nhiều điều tôi đã học được từ các cuốn sách Hành động trong phát triển SL / MVVM.

Khi tôi bắt đầu làm việc với Silverlight, tôi đã rất ngạc nhiên khi thấy nó trần trụi như thế nào và cảm giác giống như một yêu cầu phải chọn một trong nhiều khung có sẵn để mặc nó. Tôi thấy đây là một vấn đề với những người từ bỏ việc học MVVM.

Tôi đã bắt đầu với MVVM-Light tuyệt vời giúp tôi nắm bắt được mô hình. Sau đó tôi bắt đầu làm việc với Caliburn Micro và sau đó đèn bật sáng. Đối với tôi Caliburn Micro giống như sử dụng ASP.NET MVC trên ASP.NET Webforms. Vì vậy, ngay cả đối với các ứng dụng mẫu nhỏ, tôi tạo dự án, NuGet CM và tôi đang chạy và chạy. Tôi làm theo cách tiếp cận đầu tiên của ViewModel và giữ cho Chế độ xem của tôi câm và dễ làm việc trong Blend. Máy ảo của tôi có thể kiểm tra được nếu bạn tham gia và với CM, thật dễ dàng để xoay quanh các bố cục màn hình phức tạp.

Bạn có thể thích kiểm tra thay thế này. Tùy chọn này vượt qua cách WPF của cơ sở dữ liệu, bảng dữ liệu và MVVM. Tùy chọn này giống như cách tiếp cận Win.orms designer.cs cũ, đơn giản, đáng tin cậy.

Vật liệu tổng hợp WPF

http://wpfcomposites.codeplex.com/

Ở đây, mã C # phía sau ngắn gọn cho WPF được tạo ra bằng cách phủ một ma trận đơn giản lên trên giao diện người dùng thông qua các vật liệu tổng hợp dựa trên lưới. Nếu một giao diện người dùng XAML hiện đại chỉ chứa một vài nhãn văn bản và một hộp danh sách ảnh, tại sao điều này không thể được xác định bởi dòng mã đơn giản: Grid.AddText (tọa độ x, tọa độ y)? Lưu ý, điều này không nằm trên một khung vẽ, nhưng vẫn nằm trong các thùng chứa WPF: lưới, dockpanel, v.v. WPF cực kỳ mạnh mẽ. Cách tiếp cận này chỉ tận dụng điều này.

Các nhà phát triển thường không quan tâm đến ma trận và chỉ số. Bắt đầu với mức vùng chứa hạt thô được xác định bởi các đối tượng truyền dữ liệu (DTO) hoặc POCO của GUID, sau đó khen các thùng chứa có khóa này bằng một ma trận hạt mịn hơn của các hàng và cột tiềm năng bên trong?

Dự án codeplex ở trên giới thiệu cách tiếp cận này bằng cách bắt đầu với điều khiển ListBox nhưng đang mở rộng để bao gồm tất cả các điều khiển hỗn hợp WPF. Chẳng hạn, mỗi listboxitem là một hỗn hợp được thêm vào bằng GUID (một liên kết hỗn hợp một-một với một lớp), sau đó bên trong mục này có một Lưới trên đó các phần tử UI con (các phần tử con gắn một với một thuộc tính trong một lớp) có thể được thêm vào theo ý muốn thông qua mã phía sau. Trẻ em có thể là văn bản hoặc hình ảnh.

Ý tưởng là tận dụng các chỉ mục và cấu trúc Phần tử UI được xác định rõ (nó buộc một PresentationFramework.Aero theo chủ đề ListBox làm cơ sở để bắt đầu) thay vì các bảng dữ liệu. Cách tiếp cận mới này cố tình giới hạn những gì có thể được thực hiện nhưng bằng cách đó mang lại kết quả mã C # ngắn gọn, mạnh mẽ, trực quan. Không cần phải tìm kiếm các giải pháp mẫu điều khiển để tạo kiểu cho thanh cuộn hoặc làm lộn xộn một giải pháp với nhiều mẫu dữ liệu cho các tác vụ đơn giản.

MVVM chủ yếu dựa trên khung UI mà tôi đang sử dụng. Vì vậy, với một cái gì đó như WPF hoặc Silverlight có mô hình dựa trên việc liên kết với một datacontext, datacontext đó luôn có thể được gọi là mô hình khung nhìn.

Vì vậy, câu hỏi cho tôi là khi nào bạn xây dựng một lớp riêng biệt lớn, đó là mô hình khung nhìn cho điều khiển / cửa sổ / ứng dụng này và khi nào bạn có thể thoát khỏi việc sử dụng các đối tượng đã được xây dựng.

Vì vậy, chúng tôi có một câu hỏi kinh điển về việc thêm một lớp trừu tượng. VM sẽ thêm trọng lượng, quán tính và cấu trúc cho một dự án. Nó sẽ làm cho việc xây dựng dễ dàng hơn, nhưng khó thay đổi hơn và lâu hơn để xây dựng. Không ai trong số những điều đó dễ dàng định lượng.

Đối với câu trả lời rẻ tiền, MVVM không phù hợp với các ứng dụng dòng lệnh hoặc dịch vụ web :)