Access currently logged in User

Topics: Prism v4 - WPF 4
Jan 14, 2013 at 6:03 PM


How do you guys handle users logging into an application structured in a modular fashion?

I have added the Login view and associated view model directly into my Desktop application and was going to simply store my logged in user as a property in my applications' App.xaml.cs like so:

App.Current.Properties["CurrentUser"] = user;

However using this approach means I cannot access the user property throughout the application as my modules requiring access to the value would all require a reference to the App, which already has a reference to the modules.....

Is there an agreed method of passing this value or would you have a LoginModule that has a lifetime of ?????????(what) and access the value from this module, thus all modules will require a refernce to the LoginModule...... 



Jan 14, 2013 at 8:34 PM


In my opinion, a possible approach to handle this scenario could be using Shared Services to access and manage information among different modules (in this case, the logged user).

Basically, you could create a service that could store the current user, implementing an interface. Then, you could register this service in the container as a singleton mapped to that interface and import it in the modules through it. This interface could be declared in a common assembly referenced by all the modules (like an "Infrastructure" project,) while the service implementation itself could be declared in a module or in the shell project. Like this, you wouldn't need to have a reference to the project where the service is implemented, as the modules only need to know the corresponding interface.

You can find more information about Shared Services in the following section of the documentation:

Also, you can find more information about how to register a singleton in the container in the following chapter:

Damian Cherubini

Jan 15, 2013 at 10:33 AM

Thanks for response Damian

I wonder if this might be the easiest solution to my other query regarding modules of an application that are envisaged to be used by many other modules to display "child window" screens as my "Notes" module is envisaged?

Perhaps if a developer identifies such "universal" modules such as this that he/she sees as being used in many of his/her applications, they should reside in a "global"/"infrastructure" style serviceing module?

Thanks again

Jan 15, 2013 at 8:37 PM


It might be possible to create a Shared Service that could be in charge of showing a view inside a new window to manage the Notes when requested. As all the logic to do so will be encapsulated inside the service, the modules could be kept decoupled from each other. You will need to develop the logic of the service that will be in charge of doing this including how to manage the popup, pass information back and forth, etc. but you will also to be able to customize it according to your needs. Regarding this same topic, I just described another possible approach in your previous thread that you might find useful.

About your second question, I believe we should first make a distinction between a module and a infrastructure project. Based on my understanding, in a Prism application architecture an "Infrastructure" project is a project which contains resources which are "directly" used by decoupled modules and / or the main application. Such resources usually include common interfaces, common identifiers, helpers, prism extensions, etc, that are globally used. They rarely include specific implementations (like in this case Shared Services) and they are not modules (thus, they do not register classes in the container by they own.)

Following this same concept, the structure of a solution with a Shared Service could be similar to this:

  • Infrastructure (not a module) - Contains IService only.
  • Main project - Reference Infrastructure
  • ServiceModule - Reference Infrastructure - Implements Service and registers it to the container though IService
  • ConsumerModule - Reference Infrastructure - Consumes an IService injected by the container

As you can see, ServiceModule and ConsumerModule don't reference each other; however ConsumerModule can still use the service because both knows the IService interface. This is the advantage of using a Infrastructure project. The Service implementation is not in the Infrastructure project to allow decoupling the service implementation from the modules. Like this, if in the future you need to change the service, you can replace the ServiceModule without affecting the ConsumerModule. Also, this will allow you to port the ServiceModule to other applications, as long as you define the corresponding interface in the Infrastructure of that application too.

As you mentioned, by following this kind of pattern and by properly decoupling the modules, you can be able to create "universal" modules that could be reused in several of your applications.


Damian Cherubini