1

I have an application with a login screen, fairly typical scenario I guess. After the user gets authenticated, I need to store him somehow because I will then have to act based on his permissions etc. Of course there will be more properties to store as well..

What is considered the best way of achieving this? I'm currently evaluating two options:

1.) use a singleton (or a static property) and reference that in my viewmodels

2.) use App.Current.Properties and store it there. Then maybe use some static helper method to retrieve the user more easily and consistently throughout the app

Or maybe is there any other option to consider? Thank you for suggestions.

walther
  • 13,466
  • 5
  • 41
  • 67
  • It appears you are talking about storing the user in memory for the duration of session? If so why not create a User class with all the properties you need and store a reference to an instance (could be a singleton) of this user class in your main view model. You can than send a message to your main view model from any other view model that needs access to your user properties and the main view model will send a message back with a reference to that instance of your user class... – Dean Kuga May 01 '13 at 21:39
  • @DeanKuga, maybe a more specific example - in asp.net you'd use sessions to store user-specific data. Then you simply reference these session variables to retrieve anything you need from individual pages. What would be the alternative in WPF? Singletons are kinda problematic when it comes to unit testing, so I'm trying to avoid them as much as possible, even though I'm starting to believe that won't be possible. I guess sometimes the easiest solution is the best one... – walther May 01 '13 at 22:06
  • I think adding a dependence to MEF for something like this is an overkill, I don't see why it would have to be a singleton either, so I'd just create an instance of the User class at logon and send references to other view models as needed... Check out this answer about communicating between view models: http://stackoverflow.com/a/14361984/229930 – Dean Kuga May 01 '13 at 22:21
  • 1
    This was described by user Rachel in the question I mentioned above. It looks like a good fit to what you're trying to accomplish... Make an ApplicationViewModel which manages things like which page is current, and application-wide objects like the current user or current project list. It would handle transferring shared data to the ViewModels that needs it. – Dean Kuga May 01 '13 at 22:27
  • hi @walther what solution did you consider? Because i am also trying to implement the most easy to handle and best way for doing the same – wingskush Jul 01 '15 at 06:22

1 Answers1

2

Use the MEF and [Import] the authenticated user interface into your view models. This way you have a global resource available to your objects and the framework rather than your code is responsible for managing the resource. This introduces less coupling than either of your suggested solutions, which among other advantages will help with unit testing.

The Prism framework for Silverlight is based on MEF and should be adaptable to WPF.

MEF is dependency injection. You give MEF responsibility for resolving dependencies by mapping required interfaces to instances of concrete classes. You create an IAuthenticatedUser interface with methods that set and retrieve the identity. You create a model class that implements the interface and exports it to MEF. Your login ViewModel and any other ViewModel that requires the identity import the interface. MEF wires up the view models to an instance of the implementation class when it creates them. Your ViewModels use the interface as required.

antlersoft
  • 14,636
  • 4
  • 35
  • 55
  • Correct me if I'm wrong, never actually used MEF, but isn't MEF something like dependency injection? You specify some dependencies and it "magically" wires up things correctly. What would it look like in my situation? User comes in, logs in and...? How could I get this data from a ViewModel x-clicks away using MEF? What would I actually `Export`? Sorry for probably a dumb question, but in last few weeks I've made some research on way too many architecture patterns and my head is probably going to explode soon. I'd be grateful for some more concrete example. Thanks. – walther May 01 '13 at 19:53
  • Yes, MEF is dependency injection. You give MEF responsibility for resolving dependencies by mapping required interfaces to instances of concrete classes. You create an IAuthenticatedUser interface with methods that set and retrieve the identity. You create a model class that implements the interface and exports it to MEF. Your login ViewModel and any other ViewModel that requires the identity import the interface. MEF wires up the view models to an instance of the implementation class when it creates them. Your ViewModels use the interface as required. – antlersoft May 02 '13 at 18:47