My app needs to be able to store the connection string from the login module to be available to all other modules in the application, of which there are 50 or so. I originally intended to make the connection string available through broadcasting and subscribing to a new/changed connection string event, but because most/all of the 50 modules are loaded on demand they are unable to subscribe to the event during the login process since they are loaded after the login process. Based on my understanding I need a different approach to make the connection string available.
I then thought about placing the connection string in the shell and attempting to expose it to any loaded module but I cannot find a way to do that without breaking the MVVM pattern and introducing unwanted dependencies.
If anyone knows of a way to implement either of the above two options I would be very interested to know if it could be done while folowing the MVVM pattern.
I am thinking now that the best approach would be to use some variation of a singleton for the connection string as a shared service. I would love for the Unity Container to be able to store the connection string and I could use a service locator to access it in any module but I do not know how to do this. Any examples that are similar in nature have been in MEF and/or Silverlight. Has anyone done this in WPF or have an example of how to write a connection string singleton and add it to the Unity Container? A guide, tutorial, or some code snippets would be greatly appreciated!
Note: I am using Prism and Unity, Oracle on the backend and the app will be deployed on a Citrix server (where in the name of security they have blocked developers from writing to the app.config) which is why I cannot use that approach. Also will using a Singleton for the connection string cause problems when multiple users run the app off of Citrix? Will every user have their own singleton connection string? If not, then my whole question changes, is there a good approach I can use to pass/persist the connection string between all of my modules?
If you're using Prism, I would strongly recommend Unity Container registering the connection string and ctor-dependency injecting it into the various VMs that you have.
Sort of like, define the contract where other assemblies/VMs can consume it, and the implementation in the LoginModule:
class ConnectionInfo : IConnectionInfo
{
public GetConnectionString()
{
// you get the drift...!
// you should probably cache the result into a Lazy<T> impl. and just return
// that value on future calls, to save the lookup of the config.
}
}
Register it in the login module:
container.RegisterType<IConnectionInfo, ConnectionInfo>(
new ContainerControlledLifetimeManager());
And DI it in the ctor of your VMs - it's hassle-free, at this point:
public MyViewModel(IConnectionInfo connectionInfo_)
{
var connectionString = connectionInfo_.GetConnectionString();
}
I guess my preferred approach to these situations is to prefer interfaces above IEventAggregator, if I get to choose. It just makes it easier to handle situations like late created VMs not picking up IEA signals because the event signalling happened too early. That would lead to some real painful technical debt accumulation.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With