patterncsharpMajor
MVVM data binding for a video encoding form
Viewed 0 times
mvvmvideoforbindingencodingformdata
Problem
I am creating a C# WPF application. I am intending to bind all of the GUI controls via data binding to my
I have made some good headway with this, but unsure about something.
In my
and like this:
To my
etc...
My GUI has perhaps 50-100 controls/input fields (Text boxes, combo-boxes, etc.) so using the above code to bind these controls is adding up to thousands of lines of code in my
Is there a more efficient way to bind these controls, or is this pretty much it?
EDIT: Example of the GUI to help with a comment question:
Some example
```
ViewModel, rather than code behind - as per MVVM.I have made some good headway with this, but unsure about something.
In my
ViewModel, I am binding all the properties like this:private List listBoxCodec;
public List ListBoxCodec
{
get
{
return this.listBoxCodec;
}
set
{
this.listBoxCodec = value;
OnPropertyChanged("ListBoxCodec");
}
}and like this:
private string create_FormatSelectedItem;
public string Create_FormatSelectedItem
{
get { return create_FormatSelectedItem; }
set
{
create_FormatSelectedItem = value;
OnPropertyChanged("Create_FormatSelectedItem");
}
}To my
XAML like this:etc...
My GUI has perhaps 50-100 controls/input fields (Text boxes, combo-boxes, etc.) so using the above code to bind these controls is adding up to thousands of lines of code in my
ViewModel.Is there a more efficient way to bind these controls, or is this pretty much it?
EDIT: Example of the GUI to help with a comment question:
Some example
XAML: (Output)```
Solution
Unlearn WinForms.
Your view has way too many concerns.
As @TeaDrivenDev mentioned, XAML is pretty verbose... and WPF bindings will turn your view model into a very combersome mess of getters and notifying setters... if you think in WinForms.
Dragging-and-dropping 100-some controls onto a UserForm creates ugly bloated code-behind in WinForms; there's no magic in WPF (well there is, actually), having a view with 100-some controls in WPF using databindings is bound (!) to create an ugly bloated view model class.
Fine. What then?
Let's look at this UI.
Forget about the details, look at the high-level picture. What do you see? I see a
That's all your Window should care about.
You need to zoom out and stop seeing all the controls you want to see on that window, and break it down into reusable components.
I bet each expander has the same properties here:
You probably don't need a
Why not make a separate user control for each section, each with its own view model, dealing with its own data bindings?
Your view has way too many concerns.
As @TeaDrivenDev mentioned, XAML is pretty verbose... and WPF bindings will turn your view model into a very combersome mess of getters and notifying setters... if you think in WinForms.
Dragging-and-dropping 100-some controls onto a UserForm creates ugly bloated code-behind in WinForms; there's no magic in WPF (well there is, actually), having a view with 100-some controls in WPF using databindings is bound (!) to create an ugly bloated view model class.
Fine. What then?
Let's look at this UI.
Forget about the details, look at the high-level picture. What do you see? I see a
StackPanel with a number of Expander controls. Nothing unmanageable here.That's all your Window should care about.
You need to zoom out and stop seeing all the controls you want to see on that window, and break it down into reusable components.
I bet each expander has the same properties here:
You probably don't need a
Name for them. And if you do, you probably need an x:Name instead. But you probably don't. I rarely need to name controls in WPF. So the only thing that differs between each section here, is the Header text and the actual content. Right? Using a Style here would reduce the markup and make it semantically clearer that these UI elements should look the same.Why not make a separate user control for each section, each with its own view model, dealing with its own data bindings?
Context
StackExchange Code Review Q#87651, answer score: 20
Revisions (0)
No revisions yet.