Suggestions: Interface naming and packaging...

Nov 24, 2008 at 9:35 PM

Refer: Prism Drop 6
Great work. Few suggestions...

Solution in general uses DI container to register and leverage many services.
There are also many additional interfaces defined, but consumed internally by individual implementation (Modularity, Logging, Events, Regions, etc.)

Suggestion #1:
It will be helpful to use a naming convention to differentiate those interfaces primarilty intended for registering (and leveraging) using DI container.
Example: IModuleLoaderService as against IModuleLoader

-- --------------------------

The design (and consistent implementation) allows us to replace a given service with alternate implementation.
Nevertheless, the default service implementation is packaged in Microsoft.Practices.Composite.Silverlight assembly.
With this, if a given application chose NOT to use Regions, will have to touch the source to remove unwanted implementation.

Suggestion #2:
Would it be possible to organize individual service implementation as independent assemblies?
Nov 25, 2008 at 5:22 PM



If you consider that these suggestions would be helpful for the community, feel free to add them to the Issue Tracker so people can vote and they might be taken into account for future releases.


Regarding your second suggestion, the reason that some interfaces and implementations remain 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.


Keep in mind: This is not necessarily the final design of the assemblies. The drops will most likely undergo modifications until the official release.


Please let me know if this helps.


Damian Schenkelman