-1

Based on my previous question Accessing variables from XAML and object from ViewModel using Code Behind: How would I know which executes first?

Is it the code behind or the ViewModel?
I just want to make sure that my code behind executes prior the ViewModel

Community
  • 1
  • 1
JennyJane
  • 125
  • 6
  • 21
  • I believe your question is out of concrete context (concrete application design), even after studying your prev question I am in doubt what you are asking about- it is possible to completely substitute XAML by codebehind and vice versa. If you execute something in XAML then you do not do it in codebehind and vice versa. Anyway, it is interesting to see how this question willl be eventually answered – Gennady Vanin Геннадий Ванин Apr 18 '13 at 04:09
  • Hi @ГеннадийВанинНовосибирск Have you seen the related topic on my question above? I'm accessing the view model to add an item to my existing list using code behind. But I want to ensure that this happens before executing anything in my View Model. Kindly refer to the link below for further details http://stackoverflow.com/questions/16007054/accessing-variables-from-xaml-and-object-from-viewmodel-using-code-behind/16009306?noredirect=1#comment22915673_16009306 – JennyJane Apr 18 '13 at 04:12
  • 2
    This question doesn't really make much sense. After the compiler is done with the source you end up with a SINGLE class. Code is generated by the XAML and this is why .xaml.cs classes normally has `partial class` in their definition. You might be referring to when the bindings on the XAML are initialized, which is of course during `InitializeComponent();` – Aron Apr 18 '13 at 04:18

1 Answers1

4

The View and the ViewModel are both regular classes that get instantiated. This is done by calling the constructor as in any other class. So, as a simple answer to your question: Set a breakpoint in each constructor and see which one gets hit first.

There is no general answer to your question because it depends on your architecture and use case. Often, some control is bound to a property of the ViewModel of it's parent, which changes at some point. At that point your View already exists and you have no idea how long the value to which the property has been set is existing already. In other cases, your View is created for a specific ViewModel and takes it as constructor parameter.

The one way to make sure that the ViewModel exists before the View is to pass the ViewModel as a constructor parameter. The idea behind constructor parameters is to express: "This class needs existing instances of type xy to be created", which is what you are asking for. However, as you will set it as the Views DataContext in the constructor and as the DataContext can change after creation of the View, you cannot be sure that the View won't get a new ViewModel assigned after creation. Even worse, you will not be able to use your control in XAML anymore, because it doesn't have a default constructor anymore.

According to your first question, it is not really clear why the ViewModel should exist prior to the View. If you need to read a resource value from your View and assign it to a property on your ViewModel, I would expect it to be the other way around? Or are you accessing the View in your ViewModel (don't!)?

The question is, why you have to ask this question in the first place. There is something pretty wrong in your (or your bosses...) concept: View and ViewModel are two entities which should really work without knowing about each other. The idea is to build applications that could work perfectly without a single View existing by just getting/setting values on ViewModels and to have Views which would compile any run perfectly well without ViewModels, just without anything to show or do... If you try to hack this approach, you're better off not using MVVM at all.

Marc
  • 12,706
  • 7
  • 61
  • 97
  • Yeah, I apologize for the question. Maybe they(my bosses) thought that because I'm just a newbie so they could ask me to do anything even not appropriate. My boss told me that there's always an exception. But anyway, thanks for the explanation. I got it. I'm actually starting to learn programming that's why I have a very limited knowledge. But again thank you. – JennyJane Apr 18 '13 at 07:27