Làm cách nào để chọn KHÔNG sử dụng khung (Caliburn.Micro, v.v.) trong một ứng dụng MVVM cụ thể?

Tôi đã từng bắt đầu một dự án MVVM / WPF, cuối cùng đã được xây dựng và triển khai, và tôi đã nghiên cứu rất nhiều Khung công tác MVVM của Caliburn.Micro. Thực tế là: Tôi đã kết thúc việc không sử dụng Caliburn.Micro cho điều đó và cuối cùng tôi đã tự mình thực hiện một số khái niệm MVVM (cụ thể là, chỉ các lớp ViewModelBasevà RoutedCommand).

Bây giờ tôi đã được chỉ định cho một dự án lớn hơn một chút dọc theo cùng một dòng: "Ứng dụng máy tính để bàn ngoại tuyến dành cho khách hàng phong phú một người dùng", có thể nói, và tôi đã quyết định sử dụng Caliburn.Micro. Và đó là nơi "vấn đề" của tôi bắt đầu.

Tôi đã đọc trong bài đăng blog nổi tiếng này , có tiêu đề nói rằng "Nếu bạn đang sử dụng MVVM thì bạn cần một khung công tác", rằng:

"Cố gắng làm một cái gì đó như MVVM mà không có khung là một công việc khổng lồ. Hàng tấn mã trùng lặp, phát minh lại bánh xe và đào tạo lại cho mọi người suy nghĩ khác biệt .

Ít nhất với một khung bạn tránh được mã trùng lặp và hy vọng không phải phát minh lại bánh xe - cho phép bạn tập trung vào đào tạo lại mọi người. Phần đào tạo lại nói chung là không thể tránh khỏi, nhưng một khung cung cấp mã và cấu trúc hệ thống ống nước, làm cho quá trình dễ dàng hơn. "

Tôi sẽ đồng ý khi đọc lần đầu tiên nhưng trải nghiệm thực tế của tôi với Caliburn.Micro (CM) trong ứng dụng thực tế của tôi là không biết gì và mất phương hướng. Đó là, khuôn khổ đã không làm cho quá trình dễ dàng hơn, hoàn toàn ngược lại. Đọc các ví dụ lặp đi lặp lại do Rob Eisenberg cung cấp trong tài liệu không chính thức (cũng vậy) và cố gắng suy ra các mẫu sử dụng từ các mẫu được cung cấp phức tạp, và các mối quan hệ giao diện và lớp hoàn toàn gián tiếp của chúng, nơi mọi thứ dường như được thiết kế để hoạt động dựa trên tác dụng phụ, dường như không thể có của con người trừ khi bạn là một thiên tài dày dạn (xin lỗi vì những lời tán tỉnh, nhưng tôi đoán bạn biết ý tôi là gì).

Chưa kể rằng bất kỳ kịch bản tầm thường nào ở trên dường như liên quan đến các container IoC, đây là điều mà tôi chưa bao giờ làm việc và dường như giải quyết một vấn đề mà tôi thậm chí không gặp phải . Tôi không cảm thấy muốn dành nhiều giờ dự án để học những thứ đó thay vì nghĩ về vấn đề và lĩnh vực ứng dụng của mình. Tôi chỉ muốn một quả chuối, nhưng CM đã cho tôi một con khỉ đột (IoC) cầm một giỏ chuối.

Bây giờ tôi đang xem xét để quay trở lại khung MVVM tại nhà của mình - chỉ bao gồm một số ít các lớp dành riêng cho MVVM mà tôi thực sự muốn thực hiện - ít nhất tôi muốn cho CM một cơ hội, trong trường hợp tôi bị mất thứ gì đó ở đây, hoặc chỉ đơn giản là làm những việc "sai cách" ra khỏi sự thiếu kinh nghiệm và thiếu hiểu biết. Và câu hỏi là:

Có sự đồng thuận rộng rãi rằng "các khung làm cho mọi thứ dễ dàng và tự nhiên hơn", nhưng nếu tôi tình cờ gặp phải điều ngược lại, điều này có nghĩa là tôi không nên sử dụng khung, hoặc tôi đang cố gắng học sai cách? Có một manh mối mà tôi thậm chí không nên sử dụng một khung công tác ở nơi đầu tiên? Hoặc có một số cách "đúng" để tìm ra cách sử dụng CM để phát triển MVVM đơn giản?

Tôi đã dùng thử CaliburnMicro và MVVMLight và khi sử dụng Caliburn tôi thực sự cảm thấy những gì bạn cảm thấy, chắc chắn rằng nó cảm thấy thực sự kỳ diệu có thể liên kết quyền kiểm soát với tài sản chỉ bằng cách sử dụng Name = "PropertyName" thay vì Text cũ = "{Bind PropertyName}" nhưng trong kết thúc Caliburn vượt lên để làm điều kỳ diệu này, khi có sự cố xảy ra, thật khó để gỡ lỗi, để làm cho điều tồi tệ hơn họ có rất nhiều cách để làm một việc.

Nhưng khi sử dụng MVVMLight, nó rất mỏng, khi bạn sử dụng, bạn có thể nhận ra rằng nó gần giống 100% với MVVM Framework của bạn, với một số tính năng được rắc vào nó.

Tôi biết điều này không trả lời câu hỏi của bạn "Làm thế nào KHÔNG sử dụng khung" nhưng thật lòng tôi không thể khuyên bạn nên đi theo con đường đó vì nó chỉ sai, tôi cũng nghĩ bạn chỉ bị mất vì bạn sử dụng Khung đầy đủ tính năng thay vì sử dụng đơn giản một đầu tiên.

Điều quan trọng là nhận ra MVVM là gì. Đây không phải là một số chức năng được chia sẻ mà bạn không phải thực hiện lại (phân tích tệp JPEG hoặc kết nối với máy chủ cơ sở dữ liệu SQL đã cho), đó là một mẫu - một mẫu cho cách người ta có thể chọn để triển khai GUI phong phú. Vì vậy, nếu việc triển khai mẫu của bạn đơn giản và dễ hiểu, tôi không nghĩ bạn cần cảm thấy xấu hổ khi sử dụng nó hơn là một khung.

Thật vậy, tôi tin rằng toàn bộ ý tưởng khuôn mẫu đã đi quá xa. Đối với bất cứ điều gì là một mô hình, nó phải là hình dạng chung của một lớp các giải pháp. Bởi vì điều này là như vậy, dự kiến ​​các mẫu sẽ cần phải được điều chỉnh theo các hệ thống sử dụng chúng và bạn không thể làm điều đó nếu bạn cố gắng sử dụng mẫu một kích cỡ phù hợp với tất cả. Sẽ tốt hơn nhiều nếu để lại việc triển khai mẫu cho người thiết kế ứng dụng và cung cấp các thư viện đóng gói chức năng, thay vì kiến ​​trúc.

Trải nghiệm đầu tiên của tôi với WPF là sử dụng Caliburn.Micro nên điều này có lẽ khá khác biệt so với hầu hết các nhà phát triển. Tôi đã tìm thấy cả WPF và Caliburn.Micro là một đường cong học tập khá dốc, đến từ WinForms, tuy nhiên sau một số kinh nghiệm với cả hai tôi đã thấy chúng là một niềm vui khi sử dụng như một cặp. Hiện đang làm việc trong một tổ chức khác, nơi Caliburn.Micro không được sử dụng, tôi thấy rằng có RẤT NHIỀU mã hệ thống ống nước trùng lặp làm cho codebase khá cồng kềnh và phức tạp không cần thiết.

Tôi chắc chắn đồng ý rằng có một số vấn đề với Caliburn.Micro, có thể làm phức tạp việc gỡ lỗi, tuy nhiên một khi đã có kinh nghiệm thì chúng sẽ ít bị đau trở lại. Tốc độ phát triển tăng lên, mã sạch hơn và gọn hơn và khung tổng thể khuyến khích MVVM tốt hơn là đáng giá hơn đối với tôi.

Caliburn.Micro cũng không làm mất hiệu lực cổ phiếu WPF - nó chỉ xây dựng trên đầu trang, điều đó có nghĩa là bạn vẫn có thể sử dụng các tính năng WPF nếu bạn thích và sử dụng Caliburn cho một vài bit và miếng nếu bạn muốn. Điều này tương tự như cách TypeScript và JavaScript cùng tồn tại trong tâm trí tôi.

Tôi chắc chắn sẽ sử dụng Caliburn.Micro trong bất kỳ dự án WPF mới nào tôi làm trong tương lai nếu có cơ hội.

Đối với bất kỳ ai đến đây vì thất vọng với Caliburn.Micro, hãy xem khuôn khổ này: Stylet

Nó lấy cảm hứng từ Caliburn.Micro, ngoại trừ việc nó loại bỏ rất nhiều phép thuật khiến bạn mất phương hướng về những gì đang xảy ra. Ngoài ra, tài liệu này được viết bằng ngôn ngữ đơn giản hơn nhiều mà không cho rằng bạn muốn lội qua thuật ngữ kỹ thuật. Tốt hơn nhiều cho người mới bắt đầu.

Ngoài ra, Stylet có cách tiếp cận ViewModel-First. Caliburn.Micro và rất nhiều khung công tác khác có cách tiếp cận View-First, đi kèm với một số vấn đề khó xử. Nếu bạn đã rất giỏi về các nguyên tắc RẮN và mã theo khuôn mẫu, bạn có thể tìm thấy cách tiếp cận ViewModel-First một cách tự nhiên hơn vì nó có quan điểm rằng logic của bạn sẽ điều khiển hệ thống - chứ không phải khung nhìn.