Better way to access ViewModels
-
In my current way to structure a WPF-application I heavily lean on UserControls for my Views and place them in the MainWindow inside a container, usually a DockPanel. For instance in the MainWindow:
For each View I have a corresponding ViewModel. This ViewModel is instantiated inside the View's XAMl-code. In the DataContext element. For instance in the Body View:
I like this approach, because I can alter any properties in the ViewModel and see the View automatically change in the view during design time. But I have not find a good way to access any ViewModels from some class where I happened to need to alter the View through a property in a ViewModel. My current solution - which I don't like - to gain access of the ViewModels is: 1. Give each View a name in the MainWindow.xaml file.
2. Do some logic in the MainWindow to setup the ViewModels for each View.
public partial class MainWindow : Window
{
HeaderViewModel Header { get; set; }
FooterViewModel Footer { get; set; }
BodyViewModel Body { get; set; }public MainWindow() { InitializeComponent(); Header = viewHeader.DataContext as HeaderViewModel; Footer = viewFooter.DataContext as FooterViewModel; Body = viewBody.DataContext as BodyViewModel; }}
3. Then for every class where I need a ViewModel I need to pass it from the MainWindow in some way.
class SomeClass
{
public void AlterHeaderText(HeaderViewModel header)
{
// Do some logic with viewmodel.
}
}This approach works, but I don't like it. It's annoying to pass ViewModels from the MainWindow every time a class need one or more ViewModels to alter a View. Is there a solution to this approach to improve it? /BR Steffe
-
In my current way to structure a WPF-application I heavily lean on UserControls for my Views and place them in the MainWindow inside a container, usually a DockPanel. For instance in the MainWindow:
For each View I have a corresponding ViewModel. This ViewModel is instantiated inside the View's XAMl-code. In the DataContext element. For instance in the Body View:
I like this approach, because I can alter any properties in the ViewModel and see the View automatically change in the view during design time. But I have not find a good way to access any ViewModels from some class where I happened to need to alter the View through a property in a ViewModel. My current solution - which I don't like - to gain access of the ViewModels is: 1. Give each View a name in the MainWindow.xaml file.
2. Do some logic in the MainWindow to setup the ViewModels for each View.
public partial class MainWindow : Window
{
HeaderViewModel Header { get; set; }
FooterViewModel Footer { get; set; }
BodyViewModel Body { get; set; }public MainWindow() { InitializeComponent(); Header = viewHeader.DataContext as HeaderViewModel; Footer = viewFooter.DataContext as FooterViewModel; Body = viewBody.DataContext as BodyViewModel; }}
3. Then for every class where I need a ViewModel I need to pass it from the MainWindow in some way.
class SomeClass
{
public void AlterHeaderText(HeaderViewModel header)
{
// Do some logic with viewmodel.
}
}This approach works, but I don't like it. It's annoying to pass ViewModels from the MainWindow every time a class need one or more ViewModels to alter a View. Is there a solution to this approach to improve it? /BR Steffe
You're accessing the UC's directly: tight coupling. Ideally, you should be communicating only with the Main Window; using methods / an interface that works indirectly with the UC's; e.g. "set heading title". Use a static (e.g. .Current) to access "main window" and any other windows / UC's that only exist as singletons (at any given time).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
In my current way to structure a WPF-application I heavily lean on UserControls for my Views and place them in the MainWindow inside a container, usually a DockPanel. For instance in the MainWindow:
For each View I have a corresponding ViewModel. This ViewModel is instantiated inside the View's XAMl-code. In the DataContext element. For instance in the Body View:
I like this approach, because I can alter any properties in the ViewModel and see the View automatically change in the view during design time. But I have not find a good way to access any ViewModels from some class where I happened to need to alter the View through a property in a ViewModel. My current solution - which I don't like - to gain access of the ViewModels is: 1. Give each View a name in the MainWindow.xaml file.
2. Do some logic in the MainWindow to setup the ViewModels for each View.
public partial class MainWindow : Window
{
HeaderViewModel Header { get; set; }
FooterViewModel Footer { get; set; }
BodyViewModel Body { get; set; }public MainWindow() { InitializeComponent(); Header = viewHeader.DataContext as HeaderViewModel; Footer = viewFooter.DataContext as FooterViewModel; Body = viewBody.DataContext as BodyViewModel; }}
3. Then for every class where I need a ViewModel I need to pass it from the MainWindow in some way.
class SomeClass
{
public void AlterHeaderText(HeaderViewModel header)
{
// Do some logic with viewmodel.
}
}This approach works, but I don't like it. It's annoying to pass ViewModels from the MainWindow every time a class need one or more ViewModels to alter a View. Is there a solution to this approach to improve it? /BR Steffe
If you have a viewmodel for each user control, why is the setup performed in the main window anything more than adding the user control to the parent content control (a grid?)? The view should do all of its own setup, and should betotally self-contained at that point. Sure, you may have some sort of global data, but in the end, the user control and its viewmodel should really be completely self-contained, and the main window shouldn't even be involved.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
If you have a viewmodel for each user control, why is the setup performed in the main window anything more than adding the user control to the parent content control (a grid?)? The view should do all of its own setup, and should betotally self-contained at that point. Sure, you may have some sort of global data, but in the end, the user control and its viewmodel should really be completely self-contained, and the main window shouldn't even be involved.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013Look at MVVM Light or its soom to be replacement Microsoft.Toolkit.MVVM. They have there place but personally I think they can make simple things more complicated.
So many years of programming I have forgotten more languages than I know.
-
Look at MVVM Light or its soom to be replacement Microsoft.Toolkit.MVVM. They have there place but personally I think they can make simple things more complicated.
So many years of programming I have forgotten more languages than I know.
Historically (and in my experience), Microsoft's "convenience" frameworks are too generic to be even remotely useful. And the closer you get to an enterprise-sized application, the worse it gets.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
In my current way to structure a WPF-application I heavily lean on UserControls for my Views and place them in the MainWindow inside a container, usually a DockPanel. For instance in the MainWindow:
For each View I have a corresponding ViewModel. This ViewModel is instantiated inside the View's XAMl-code. In the DataContext element. For instance in the Body View:
I like this approach, because I can alter any properties in the ViewModel and see the View automatically change in the view during design time. But I have not find a good way to access any ViewModels from some class where I happened to need to alter the View through a property in a ViewModel. My current solution - which I don't like - to gain access of the ViewModels is: 1. Give each View a name in the MainWindow.xaml file.
2. Do some logic in the MainWindow to setup the ViewModels for each View.
public partial class MainWindow : Window
{
HeaderViewModel Header { get; set; }
FooterViewModel Footer { get; set; }
BodyViewModel Body { get; set; }public MainWindow() { InitializeComponent(); Header = viewHeader.DataContext as HeaderViewModel; Footer = viewFooter.DataContext as FooterViewModel; Body = viewBody.DataContext as BodyViewModel; }}
3. Then for every class where I need a ViewModel I need to pass it from the MainWindow in some way.
class SomeClass
{
public void AlterHeaderText(HeaderViewModel header)
{
// Do some logic with viewmodel.
}
}This approach works, but I don't like it. It's annoying to pass ViewModels from the MainWindow every time a class need one or more ViewModels to alter a View. Is there a solution to this approach to improve it? /BR Steffe
You could use singletons. I posted an article that uses singletons for app settings, the connection string for a database, and the DAL object I use to access the database. If you look at the source code, you'll see how to do it (or at least, how I did it). Entity Factory - Get Your ORM-less Freak On![^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013