Define a field and use it within MainViewModel

Question

Before using MVVM-light and start learning how to use, I defined a field in MainWindow.xaml.cs to hold a list of strings for using within the same file.

// MainWindow.xaml.cs
public static List<string> FieldName = new List<string>();

Now I am confused what is the best way to use/write the field and use it within MainViewModel.cs to observe the MVVM pattern?

Way 1: Define the field in the MainWindow.xaml.cs and use it within MainViewModel.cs by calling MainWindow.FieldName.

Way 2: Define the field in MainViewModel.cs and use it simply. If this is okay, then what is the best way to define the field?

Thanks.

Second is correct option and you can only bind with properties and not with fields. — Rohit Vats, Aug 04 '14 at 18:43
You can't bind to fields, so all this field talk is pointless. You would normally expose data in properties within your ViewModels that are then bound directly to elements in the UI. That's how MVVM works. Why you're creating a list of stuff in the codebehind of the window is unclear. — , Aug 04 '14 at 19:34
Thanks @RohitVats. If I don't want to bind to the field, is only defining a field (not with a property) enough? — Alex, Aug 04 '14 at 19:50
If you're not binding it to the ui then you can use just a field — reggaeguitar, Aug 04 '14 at 19:52
Thanks @Will. I use the field for holding a ListBox items to search through them. _If You have a better way to search through a ListBox items, please let me know. Thanks again._ — Alex, Aug 04 '14 at 19:54
@Alireza - As per MVVM, ViewModel should not know anything about View. So, in case you want to use this field in VM, define it in your VM and not in View code behind. — Rohit Vats, Aug 04 '14 at 19:56
If you're using it as the source for ListBox then it is bound to the ui and you need an ObservableCollection if it will change — reggaeguitar, Aug 04 '14 at 19:56
Thanks @RohitVats. I got my answer with your first comment. I have another question from You. If I don't want to bind the field, is defining only a field (not with a property) enough? — Alex, Aug 04 '14 at 20:07
You have to bind it to the view if you want it to display in a ListBox — reggaeguitar, Aug 04 '14 at 20:10
@RohitVats I have another question again. If I have to define a simple field in a ViewModel, so what should I write in a UI code behind class? — Alex, Aug 04 '14 at 20:14
If you're doing MVVM properly, you shouldn't have any code in the code-behind files at all except for the autogenerated stuff. Everything you need in your view is in your ViewModel. The way to connect the two is the DataContext and data binding — reggaeguitar, Aug 04 '14 at 20:16
https://www.youtube.com/user/TheCamronBute/videos watch the introduction to MVVM and introduction to MVVM Light videos — reggaeguitar, Aug 04 '14 at 20:17
Thanks @reggaeguitar. Your answers and other answers helped me so much. Thank You all. — Alex, Aug 04 '14 at 20:22

score 0 · Answer 1 · answered Aug 05 '14 at 07:38

0

Define the property (not field) in MainViewModel and use it (for example bind the view to it).

answered Aug 05 '14 at 07:38

romanoza

4,775
3
27
44

Thanks for your answer. I got very good answers last night. I don't want to bind the field, so declaring only a field (not with a property) is enough for me. – Alex Aug 05 '14 at 08:40

score -2 · Answer 2 · edited May 23 '17 at 10:26

I'm also getting started in WPF, but to begin with, I've hear it's BAD to use fields in databinding (which you will use a lot in WPF). You need to use properties (One of the biggest advantages is to use INotifyPropertyChanged), but I've heard it's also good practice to consolidate all your fields and datacontexts inside one MainViewModel like so:

public class MainViewModel 
{
    MyDataContext datacontext = new MyDataContext();
}

public class MyDataContext
{
    public static List<string> FieldName = new List<string>();
}

(IMPORTANT: This does not implement FieldName as a property, I didn't implement it for the sake you read the post below, just wrote that to demonstrate how to encapsulate properties and objects into one DataContext)

This lets you have only one DataContext established while still letting you access other ones inside the main one. Also, don't forget to use DependencyProperty, or implement INotifyPropertyChanged in your class with fields so you get notified when it changes.

Here is a simple property implementation for demonstration:

private string _MyProperty;

public string MyProperty
{
    get { return _MyProperty;}
    set { _MyProperty = value;}
}

To start with, you need to convert that field into a property, here is a post explaining that: How to create a property for a List<T>

Then don't forget to implement INotifypropertychanged if you want your changes to reflect on your UI: Implementing INotifyPropertyChanged - does a better way exist?

It's not only a bad idea, it is even no option at all, because it will not work. Data binding only works with public properties. "I'm also getting started in WPF", maybe it is too early for you to write answers on StackOverflow. — Clemens, Aug 04 '14 at 19:00
I always learn from people that ask questions or write their wrong answers; because people with good knowledge comment on their answers. Thank You all. — Alex, Aug 04 '14 at 19:58
I tried to add a comment on your question but I lacked the reputation to do so -.- I can only comment on my own questions/answers, thanks for the comment... — sgarcia.dev, Aug 04 '14 at 21:05

Define a field and use it within MainViewModel

2 Answers2