Design Principles, please read P&P folks

Nov 22, 2008 at 11:26 AM

I'm using PRISM V1 in my app's and i really appreciate the work you guys have done!

But one thing that really bothers me is the fact that you include in the same assembly (Composite) both the interfaces and implementations. My modules only depend on the interface IModule and they shouldnt have access to the core implementations of the module loaders or enumerators or whatesoever. I'd rather depend on Composite.Common.dll or something like that, which would have only the common interfaces that modules would need to access, while the Composite.dll would be available to the application that has the bootstrapper, for the initializations.

I dont know why you didnt separate things in PRISM V1, and you still havent done it in PRISM V2, so i guess there must be a good reason for it and i'd like to know :)

If you're thinking in ever changing it, i'm sure me and a lot of ppl would be grateful.

In the meantime, keep up the good work!

Nov 24, 2008 at 8:09 PM



The first drops of the Composite Application Guidance for WPF did have completely separated the interfaces from their implementation. The team decided to change this design to separate UI-specific components from common components used by Composite Applications:

·         The Microsoft.Practices.Composite assembly contains the implementation of the Composite Application Library core components such as modularity, logging and communication services, and several core interfaces’ definitions. This assembly does not contain UI-specific elements and could be potentially used for both WPF and Winforms applications.

·         The Microsoft.Practices.Composite.Wpf assembly contains the implementation of Composite Application Library components that target Windows Presentation Foundation applications including commands, regions, and events.


The reason that some interfaces and implementations remains in the same assembly is to keep a simpler usage and avoid you having to add more references to your projects, or if you prefer to consume the library as source code, avoid having several projects in your solution. Having separate assemblies for interface would trigger an assembly explosion that goes against the simple first principle.


Do you have a concrete scenario where having implementations close to the interfaces would be a problem? If so, please let us know, so the Prism team can take the feedback into account.

Furthermore, please feel free to add a Workitem in the Issue Tracker to let the people vote it and perhaps your suggestion could be consider for future releases.


Please let me know if this helps.


Mariano Converti

Nov 25, 2008 at 12:28 AM
Hi Mariano,

Thanks for your reply. I understand your point of view. Keep it simple and usable from both WPF and Windows Forms.

But now imagine deploying modules which will be downloaded from a remote server, like the silverlight aproach.These modules have to reference an assembly that can potentially grow-up in size, when it would be preferable to have references to an assembly that has only a couple of interfaces, thus decreasing the download size.

Also, the implementations usually tend to change but not the interfaces, so they should be separated.

Nov 26, 2008 at 1:50 PM
Edited Nov 26, 2008 at 1:51 PM
Hi MFelicio,

Regarding the concern about size in the module deployment, this needn't be an issue, because you can assume that those 2 DLLs will be already loaded in the context of the application, so you don't need to deploy those assemblies with your modules.
You can accomplish this by setting Copy Local to false on the reference properties from your modules.

Regarding your other concern, about interfaces being less prone to change (and versioning), it is true. But here is where simplicity on the use comes in to play, and balances the scale. It also simplifies versioning of the release, because all DLLs can have the same version number, and it's easier to upgrade and to create the release for us.

If you think separating the interfaces is a very important feature, please feel free to add it to the issue tracker and have people vote on it. We are really driven by the community, so if we find that this is something that many people want and outweights the simple use scenario, we will probably include it.

Let me know your thoughts about this.

Julian Dominguez