prism and WF with persistence

Topics: Prism v4 - WPF 4
Aug 8, 2013 at 7:54 AM
Edited Aug 8, 2013 at 8:32 AM
I am creating a WPF application with PRISM, but this application is also using workflows.
These workflows are long running workflows so they need to be persisted to the database. I am using the standard sql server mechanism to do that.
I am also using WorkflowApplication to create instances of the workflows and store the Guid in a database table of my own, so I can get to the flow at any state.
Because of this I have to register the host application to the instance store, but also unrgister it.
I am doing the registration in the initialize of a dedicated IModule, I am also registering the InstanceStore to the container.
How am I supposed to take care of the unregistering when the application dies ?
Should I implement IDisposable on the module and do the necessary steps to make sure the cleanup is called even though I am not explicitely calling dispose myself (as in ?
Or is there a better way ?

IModule is definitely not the proper place because it is already being garbage collected way before the end of the application. At least in my case it is.
So my strategy now is to implement a manager that receives the store via dependency injection. In the constructor of the manager I am registering of the host and in dispose i am doing the deregistration of the host. I think I have to consider this unregistration as an unmanaged resource. otherwise it is not called.
Aug 8, 2013 at 4:47 PM

Based on the scenario you described us, implementing IDisposable on your manager could make the manager instance to be garbage collected if it is not being used and your application needs more resources. Therefore, a possible approach to solve your problem could be to define the manager as an IModule and register it in the container as a Singleton. By doing this, the manager instance won't be erased and you may work with the same manager through the entire application lifetime. Notice that if you are using Unity, you should register the module as follows, since Unity registers modules as not-Singleton by default:
this.container.RegisterType<ManagerModule>(new ContainerControlledLifetimeManager());

Registering the host inside the Initialize method of the manager´s IModule class, will only execute it on the first resolve action, so you can be sure that the registration won't be done twice.

Regarding the deregistration, you could make the manager subscribe to an event, raise that event through EventAggregator when you want to, and then deregister the host through the manager's module event handler.

If this doesn't help you, it would be useful if you can provide us with more detail of the design of your application or a sample so we can analyze in further detail your scenario.


Federico Martinez