I have developed a WPF application using Prism and Unity frameworks and I have some concerns regarding the following whether I have implemented them correctly or not.
Abstract classes / Interfaces - I have organized interfaces for all the layers in one assembly and then referenced it in the respective library for implementation. Now, the referenced library has access to all the non required interfaces of other layers. For e.g. the service layer has access to UI interfaces. Is this the proper implementation in terms of clear separation or should I split it into multiple assemblies.
View Model dependencies - I used EventAggregator mostly to communicate between view models. In some cases, I am passing the instance of other view models directly in the constructor and resolving it using DI container. I want to omit the direct view model dependency by introducing the interface to achieve clear separation. How can I organize the interface for view models into a separate assembly in such a way that the other developers could understand.To avoid creating multiple UI projects, I created only one single assembly and logically separated them into folders.
Abstract Module Class - Instead of specifying all the dependencies in bootstrapper.cs file, I factored them in respective module. Most of my class lib projects has references to Prism libraries. Thus, UI specific namespaces are added to non UI related projects. Is there any better approach to achieve this ?
Abstract classes / Interfaces
I'd go for exactly as many "interface-assemblies" as necessary, having too many of them hurts. Example: if you need to prevent layer 1 from potentially communicating with layer 3, put the layer 1-to-layer 2-interfaces in one assembly and those for layer 2-to-layer 3 in another one.
View Model dependencies
Normally, you shouldn't need to pass view models around at all. Pass around the data (a.k.a. model), the view models themselves don't hold any data that's either unavailable elsewhere or valuable to anyone but the view bound to the view model.
Abstract Module Class
Your prism application references prism... so what? As long as only the IModule implementations receive the IUnityContainer I wouldn't care at all. If someone needs to publish an event, he get's the IEventAggregator... That's an interface already, and you can inject a mock in your tests, so no need for further abstraction.