Prism Features (Desired and Existing)

May 9, 2008 at 9:08 AM

Prism Features (Desired and Existing)


I do apologise if this thread is in anyway redundant or improperly placed, but I wanted to provide the community with a place where we could discuss the features Prism has and the sort of features Prism might should possess. Furthermore, if this post seems inappropriate or inaccurate in anyway, I apologise as I have never commented in a Codeplex forum before and I am not the most experienced developer.

I have to keep this brief as I simply don't have time for much of this fun at the moment.


What Prism has

Presentation Model (MVVM)
From what my team has done on top of CAB, I'm happy to see a very similar implementation of the Presentation Model pattern in Prism. The pattern is new to us, and, though data-binding support has been available for a while (implying MVVM should have maybe been around in SCSF v2) it is a tremendous movement and improvement for the community.


What Prism could use:

Dynamic Module Loader/Unloader
I've noticed that, for the moment, the Prism module loading sequence and scope strongly resembles CAB's. My company would especially like to see the module loading abstracted in terms of two dimensions, and be complimented by a module unloading service. We think it'd be groovy if a service was in place to provide dynamic assembly loading, both within the default and specified application domains (must be specified for unloading to occur). Clearly, some sort of application domain would need to be created under the default for anything that is to get loaded after the bootstrapper so that unloading can occur Given that service exists, it would then be extra groovy if it was somehow able to be hooked, such that a custom reflection/initialisation sequence of the loaded assembly could be executed (envision traditional IModule loader sitting atop this, and even customised assembly mini-module loading). Given all this is done properly, assembly (module) unloading can occur (by dropping application domains, as I'm not familiar with any other way). This feature is very important to us, and (from what I can tell) other teams as well, as not requiring an application to be restarted to perform clearly very powerful manipulation provides better value to our customers (and meets requirements as well).


Looking forward to hearing everyone's feedback.

Cheers
~michael.
May 9, 2008 at 3:15 PM
System.AddIn?
May 10, 2008 at 4:12 AM
If you were to think System.AddIn could solve this problem, I'd also expect that you'd question why a module loader exists in CAB/Prism at all.

Anyway, though AddInAttribute could be applied to assembly that is eventually parsed by a module loader, perhaps to invoke some sort of custom behaviour, it's not really ideal for a composite application, as it implies that the marked up assembly knows something about how/why it's being used.  I think it's more appropriate for there to be a component that initiates dynamic module/assembly loading when it deems appropriate and places them in the application domain it deems appropriate.  In essence, it is a controller/owner of these modules/assemblies and the corresponding application domain.
May 10, 2008 at 4:29 AM
I forgot to add that, the reason module loading should be refactored out of the CAB/Prism application codebase (so to speak) and made a service, along with an inverse unloading service, is because of the DRY principle.  When my team is having to create a service with almost identical code to the module loader that already exists, there's a problem, and for many reasons, we don't like to change the underlying code and we like to use the signed assemblies.

This also reminds me of a sour taste that CAB seems to leave in many team's mouths once they reach a certain point in their development cycle.  CAB, along with all of its documentation does a decent job of getting an application and all of it's components loaded and visible, but then what?  You have a fully ramped up application that doesn't lend itself easily to "undoing" what you've done.  Closing components and cleaning up after yourself isn't well documented or supported.  I think it would be a good idea for the Prism team to provide more documentation and support on this for teams that might be just becoming familiar with the composite application paradigm and considering using Prism.
May 11, 2008 at 3:57 AM

@happi_mike

Prism supports 4 kinds of module loading, one static style (the RI) and 3 dynamic including loading on demand. If you look in our modue loading quickstarts you can see how this works. We deliberately did not bring this into the RI, because we wanted to illustrate that Module is foremost a logical separation.

Additionally, the module loading is implemented through services, and they have no coupling whatsoever to the rest of the Prism library code. You can literally take our module loading services (ModueLoader and ModuleEnumerator) and plug them in to any new or existing application. You can also easily replace either the enumerator or the loader with your own implementations.

 

May 11, 2008 at 4:16 AM
@jarrettv

Conceptually, System.Addin sounds like it could solve the problem. After two weeks of spiking with it, we decided it that in our scenarios, it was creating more problems than it was solving :)

System.Addin is great for solving some really complex scenarios, like when you absolutely MUST have app domain isolation, or you want to have instrumentation around modules. However for the normal cases, it's overkill to implement it.
May 11, 2008 at 11:28 PM
@gblock

Thanks for your response, Glenn.  Sorry if I've made the mistake of not recognising the Prism Module Loader as a dynamically reusable service... I must've missed something.  Anyway, I've noticed your team has gone to great lengths to decouple the services, especially with the IoC container.  We definitely appreciate your team's good work.
May 12, 2008 at 1:26 AM
Thanks Mike.

We felt strongly that this was the right decision (decoupling). Glad to hear you are seeing it has value.