Tôi đang xây dựng một ứng dụng giống như Visual Studio trong WPF và tôi đang gặp một số vấn đề xác định tổ chức thiết kế kiến trúc tốt nhất của các thành phần của tôi. Tôi có kế hoạch sử dụng Unity như container phụ thuộc của tôi tiêm và Visual Studio đơn vị kiểm tra khuôn khổ và có lẽ moq cho thư viện mocking.MVVM với thiết kế kiến trúc Unity và Unit Testing
đầu tiên tôi sẽ mô tả cấu trúc của giải pháp của tôi, sau đó câu hỏi của tôi:
tôi có một dự án WPF có chứa:
- My khởi chứa Unity (bootstrapper) khi khởi động ứng dụng (trong App.xaml.cs)
- Tất cả lượt xem ứng dụng của tôi (XAML).
Một dự án khác được gọi là ViewModel này chứa:
- Tất cả ViewModels ứng dụng của tôi. Tất cả ViewModels tôi kế thừa từ một ViewModelBase đó cho thấy một tài sản ILogger
Logic khởi của tôi là như sau:
- ứng dụng Startup
- Unity tạo container và đăng ký các loại: MainView và MainViewModel
- Giải quyết MainView của tôi và hiển thị nó.
var window = Container.Resolve<MainView>();
window.Show();
constructor MainView tôi nhận được một đối tượng MainViewModel trong constructor của nó:
public MainView(MainViewModel _mvm)
MainViewModel của tôi có một ViewModel Child cho mỗi tấm của nó:
public ToolboxViewModel ToolboxVM{get; set;} public SolutionExplorerViewModel SolutionExplorerVM { get; set; } public PropertiesViewModel PropertiesVM { get; set; } public MessagesViewModel MessagesVM { get; set; }
Và tôi đang lập kế hoạch tạo phương thức InitializePanels() khởi tạo từng bảng.
Bây giờ ở đây câu hỏi của tôi: Làm thế nào có thể MainViewModel.InitializePanels() của tôi khởi tạo tất cả các bảng đó? cho các tùy chọn sau:
Lựa chọn 1: Khởi tạo ViewModels bằng tay:
ToolboxVM = new ToolboxViewModel();
//Same for the rest of VM...
Nhược điểm:
- tôi không sử dụng container Unity nên phụ thuộc của tôi (ví dụILogger) không được tự động giải quyết
Phương án 2: Sử dụng setter tiêm bằng cách chú thích tài sản của tôi:
[Dependency]
public ToolboxViewModel ToolboxVM{get; set;}
//... Same for rest of Panel VM's
Nhược điểm:
- Tôi đã đọc rằng Unity Setter phụ thuộc nên tránh vì chúng tạo ra sự phụ thuộc với Unity trong trường hợp này
- Tôi cũng đã đọc rằng bạn nên tránh sử dụng Unity for Unit Tests, vì vậy làm thế nào để làm cho sự phụ thuộc này rõ ràng trong các Bài kiểm tra Đơn vị của tôi? Có nhiều thuộc tính phụ thuộc có thể là một cơn ác mộng để cấu hình.
Lựa chọn 3: Sử dụng Unity Constructor tiêm để vượt qua tất cả ViewModels Bảng điều chỉnh của tôi để các nhà xây dựng MainViewModel vì vậy họ sẽ được tự động giải quyết bằng Unity container:
public MainViewModel(ToolboxViewModel _tbvm, SolutionExploerViewModel _sevm,....)
Ưu điểm:
- Sự phụ thuộc sẽ hiển nhiên và rõ ràng tại thời điểm tạo ra, điều này có thể giúp xây dựng các đơn vị ViewModel của tôi.
Nhược điểm:
- Có rất nhiều thông số nhà xây dựng có thể nhận xấu xí khá nhanh chóng
Lựa chọn 4: Đăng ký tất cả các loại máy ảo của tôi tại tích tụ chứa. Sau đó đi qua các ví dụ UnityContainer qua constructor injection để MainViewModel tôi:
public MainViewModel(IUnityContainer _container)
Bằng cách đó tôi có thể làm một cái gì đó như:
Toolbox = _container.Resolve<ToolboxViewModel>();
SolutionExplorer = _container.Resolve<SolutionExplorerViewModel>();
Properties = _container.Resolve<PropertiesViewModel>();
Messages = _container.Resolve<MessagesViewModel>();
Nhược điểm:
- Nếu tôi quyết định không sử dụng Unity cho UnitTests của tôi, như nhiều người đề nghị, sau đó tôi sẽ không thể giải quyết và khởi tạo Panel ViewModels của tôi.
Cho rằng lời giải thích dài dòng, cách tiếp cận tốt nhất để tôi có thể tận dụng lợi thế của Thùng chứa phụ thuộc và kết thúc với giải pháp Đơn vị có thể kiểm tra là gì ??
Cảm ơn trước,
Bạn hoàn toàn đúng. Tôi nên mã chống lại giao diện và không thực hiện cụ thể, tuy nhiên, tôi thường bắt đầu mã hóa các lớp cụ thể và sau đó trích xuất các giao diện của họ với Resharper, chưa đạt đến điểm đó, nhưng tôi sẽ sớm! –
Giải pháp nhanh chóng và bẩn thỉu của tôi cho điều này là để khởi tạo các mô hình xem của tôi trong app.xaml dưới dạng tài nguyên, sau đó kết hợp khi cần thiết. '