2010-06-01 25 views
7

Tôi đang ở giai đoạn hoàn thành của một dự án lớn có nhiều thành phần lớn: thu nhận hình ảnh, xử lý hình ảnh, lưu trữ dữ liệu, I/O nhà máy (dự án tự động hóa) và một số mục khác.MVVM và tránh đối tượng Thiên Chúa nguyên khối

Mỗi thành phần trong số này là độc lập một cách hợp lý, nhưng để dự án chạy toàn bộ, tôi cần ít nhất một phiên bản của mỗi thành phần. Mỗi thành phần cũng có một ViewModel và View (WPF) để theo dõi trạng thái và thay đổi mọi thứ.

Câu hỏi của tôi là phương pháp an toàn nhất, hiệu quả nhất và dễ bảo trì nhất trong việc khởi tạo tất cả các đối tượng này, đăng ký một lớp với Sự kiện ở một sự kiện khác và có ViewModel và Chế độ xem chung cho tất cả điều này.

Sẽ tốt nhất nếu tôi có một lớp được gọi là Thiên Chúa có cá thể riêng của tất cả các đối tượng này? Tôi đã làm điều này trong quá khứ và hối hận.

Hoặc sẽ tốt hơn nếu Thiên Chúa dựa vào trường hợp Singleton của những vật thể này để có được quả bóng lăn.

Ngoài ra, nên Program.cs (hoặc bất cứ nơi nào chính (...)) khởi tạo tất cả các thành phần này và chuyển chúng đến với Chúa làm thông số và sau đó để cho Ngài (snicker) và giao diện ViewModel của mình với các đặc điểm của hoạt động dự án này.

Bất kỳ đề xuất nào khác mà tôi muốn nghe.

Cảm ơn bạn!

Trả lời

2

Cách ưa thích của tôi là có được ViewModels đang sử dụng ViewModelLocater. Về cơ bản nó là đối tượng của Thiên Chúa như bạn ngụ ý, nhưng nó chỉ có trách nhiệm là tạo ra mỗi ViewModel và giữ một tham chiếu đến nó. Tôi thường thêm VML vào tài nguyên của ứng dụng và mỗi khung nhìn chịu trách nhiệm thiết lập DataContext của nó cho ViewModel chính xác. Nếu bạn đang đăng ký nhiều sự kiện, bạn có thể có VML nối chúng theo cách thủ công, hoặc nó có thể tạo VM để ném các sự kiện trước và chuyển nó đến VM phụ thuộc trong hàm khởi tạo của nó.

+0

Tôi đã thử mọi cách tiếp cận không thuộc bên thứ ba ở ngoài đó, mọi nỗ lực ngoại trừ lần thử cuối cùng là thất bại ở một mức độ nào đó và cuối cùng giải quyết một điều gì đó rất gần với mẫu ViewModelLocater của bạn. Tôi chắc chắn rằng các khuôn khổ của bên thứ ba mà những người khác đã đăng sẽ giúp tôi tiết kiệm rất nhiều công sức, nhưng tôi đã quá muộn vào dự án vì điều đó. Câu trả lời này là một nền tảng trung bình tốt. Tôi lấy nó, bạn đã học được cách khó khăn quá. Dù sao, ở đây chúng tôi là vài tháng sau đó nhưng - cảm ơn bạn! – bufferz

0

Tôi hy vọng tôi đã hiểu rõ câu hỏi của bạn. Tôi nghĩ rằng bằng cách sử dụng một Thiên Chúa ViewModel nó không phải là một ý tưởng tốt. tốt hơn là có một viewmodel duy nhất cho mỗi chế độ xem của bạn và khởi tạo tất cả các mô hình chế độ xem có liên quan trong chế độ xem đó. sau đó bạn có thể sử dụng một người hòa giải để gửi tin nhắn giữa các chế độ xem của chế độ xem đó và các chế độ xem khác, một cách an toàn. tôi cũng propuse để sử dụng lệnh wpf thay vì các sự kiện. bạn có thể tìm thấy một bài viết tuyệt vời về hòa giải viên trong here.

3

Những mối quan tâm được đưa về chăm sóc khá độc đáo sử dụng của Microsoft "Thư viện Composite Application" (aka Prism) một khuôn khổ cho việc phát triển tổng hợp các ứng dụng WPF:

http://msdn.microsoft.com/en-us/library/ff647752.aspx

http://msdn.microsoft.com/en-us/library/ff648611.aspx

  • Soạn quan điểm của bạn: Lăng kính có khái niệm về cửa sổ trình bao ứng dụng và trình quản lý vùng. Hệ vỏ hoạt động như một trang bố cục trống, trong đó bạn xác định các vùng có tên là nơi đặt, ví dụ: "MainMenu" và "TabInterface". Bạn bao gồm các tham chiếu đến lượt xem và chế độ xem của bạn trong các lớp mô-đun, ví dụ: "MainMenuModule" và "TabInterfaceModule" và xác định khu vực mà mô-đun sẽ được liên kết với. Prism sẽ tạo các khung nhìn của bạn và đưa chúng vào các vùng vỏ khi ứng dụng khởi động. Điều này cho phép bạn soạn các khung nhìn độc lập với nhau.

  • Giao tiếp giữa chế độ xem: Lăng kính hỗ trợ mẫu hòa giải được gọi là "Event Aggregator". Về cơ bản, bạn có thể xuất bản và đăng ký thư thông qua trình thu thập sự kiện từ các chế độ xem của bạn. Điều này cho phép viewmodels giao tiếp lỏng lẻo thông qua tin nhắn, thay vì phải biết về nhau và hooking sự kiện.

Prism ủng hộ và hỗ trợ các mẫu để phát triển các thành phần độc lập với nhau theo cách lỏng lẻo, không giới thiệu đối tượng Thiên Chúa và ghép nối. Một phần lớn của Prism cũng là việc sử dụng IOC và tiêm phụ thuộc, vì vậy việc kiểm thử đơn vị trở nên dễ dàng hơn nhiều.

Tôi tìm thấy bài viết sau đây giới thiệu thực tiễn tốt để sử dụng Prism và MVVM:

http://www.developmentalmadness.com/archive/2009/10/03/mvvm-with-prism-101-ndash-part-1-the-bootstrapper.aspx

3

Hãy xem một số khuôn khổ dependency injection như Unity (mà CAL sử dụng), Lâu đài Windsor hoặc mùa xuân. MẠNG LƯỚI.

1

Bạn có thể sử dụng Bộ điều khiển (ApplicationController, Use-Case Controllers) thay vì một lớp 'Thiên Chúa'. Các bộ điều khiển chịu trách nhiệm tạo ra các đối tượng ViewModel và chúng làm trung gian giữa chúng.

Cách hoạt động này được hiển thị theo dự án WPF Application Framework (WAF).

Các vấn đề liên quan