Cheat Engine

[Fafaffy]

Okay, so I'm learning WPF and as atomos brought up to me, there is an MVVM standard. Now I've been trying to make random programs to practice this standard, but I have a situation that I'm not sure of how to proceed.


I have a model called Account; this contains a username, password, etc... of the account that is currently signed into the program. Saying this, there should only be one instance of account (you can't sign into multiple accounts) and it should be accessible by any viewmodel when required.

Now, I initialize this class in my MainWindowViewModel, and bind (via string) the title of the window to contain the username, etc... This is used by the MainWindowView to dictate what to put on the window title bar.

When you first start up the program, you're not signed in, so I created a new view (which is a usercontrol located within the main window) called LoginView. This view, from my understanding of MVVM, should have its own viewmodel for easier maintainability (which means I can't just "borrow" the datacontext from the main view). Additionally (as far as I'm concerned), I'm not allowed to require a parameter for the constructor to get the instance of the Account class.


Now my question is, how - within the Login View Model - can I get the Account instance located within the Main view while staying pure to MVVM?

I thought of a few solutions, but... I feel as if this doesn't follow MVVM Standards:
- Create a singleton class of the Account model, but this was a big no-no from everywhere I google'd.

- Use a messaging class. I'm not too familiar with how to implement this, and from what I saw (which may be very wrong), I had to use a view locator to grab a static instance of another view. I think this is against the principle of coupling view models, and again, I want to stay pure to MVVM.


Picture to describe my situation:

[atom0s]

Singleton's are usually frowned upon since usually there is a better method of doing things, but that is not to say they cannot be used or are horrible. They are very helpful and can be very useful depending on the situation. Given that you are using a single instance of this class there is no reason to make a singleton out of it.

Instead you can do a few things:

1. Use a static model instance of the Account object. You can do this by creating an App wide static instance of the object inside of App.xaml. You would do something like this: