Explore topic-wise InterviewSolutions in .

MVVM facilitates a clear SEPARATION of the development of the UI from the development of the business logic or back END logic KNOWN as the model (also known as the data model to distinguish it from the view model). The view model of MVVM is a value converter. MVVM was DESIGNED to make use of data binding functions in WPF to better facilitate the separation of view layer development from the rest of the PATTERN by removing virtually all GUI code (“code-behind”) from the view layer.

MVVM facilitates a clear separation of the development of the UI from the development of the business logic or back end logic known as the model (also known as the data model to distinguish it from the view model). The view model of MVVM is a value converter. MVVM was designed to make use of data binding functions in WPF to better facilitate the separation of view layer development from the rest of the pattern by removing virtually all GUI code (“code-behind”) from the view layer.

The INotifyPropertyChanged interface is used to notify clients, TYPICALLY binding clients, that a property value has changed.For EXAMPLE, consider a STOCK object with a property called StockCount.
To provide generic property-change notification, the Stock type implements the INotifyPropertyChanged interface and raises a PropertyChanged EVENT when StockCount is changed.For change notification to occur in a binding between a bound client and a DATA source, your bound type should either:

• Implement the INotifyPropertyChanged interface (preferred).
• Provide a change event for each property of the bound type.

The INotifyPropertyChanged interface is used to notify clients, typically binding clients, that a property value has changed.For example, consider a Stock object with a property called StockCount.
To provide generic property-change notification, the Stock type implements the INotifyPropertyChanged interface and raises a PropertyChanged event when StockCount is changed.For change notification to occur in a binding between a bound client and a data source, your bound type should either:

• Increases the “Blendability” of your views (ability to use Expression BLEND to design views) – This ENABLES a separation of responsibilities on teams that are lucky enough to have a designer and a programmer… each can work independent of the other.
• “Lookless” view logic – Views are AGNOSTIC from the code that runs behind them, enabling the same view logic to be reused across MULTIPLE views or have a view easily retooled or replaced. Seperates concerns between “behavior” and “style”.
• No duplicated code to update views – In code-behind you will see a lot of calls to update view controls. With MVVM you can be assured the view is updated APPROPRIATELY just by setting the underlying property and all view side-effects thereof.
• Testability – Since your logic is completely agnostic of your view, unit testing is made easy. You can test the behavior of a ViewModel without involving its view. This also enabled test-driven development of view behavior, which is almost impossible using code-behind.
• Designer-Developer Workflow – MVVM facilitates a separation of UI and presentation logic concerns from the business layer that makes it easy to streamline the development process by allowing design cycles to happen in parallel with development.

ICommand defines a command The ICommand TYPE exposes the following MEMBERS.

• CanExecute :Defines the method that determines whether the command can EXECUTE in its current state.
• Execute :Defines the method to be called when the command is INVOKED.
• CanExecutehanged :Occurs when CHANGES occur that affect whether or not the command should execute

ICommand defines a command The ICommand type exposes the following members.

An event is a programming construct that reacts to a CHANGE in state, notifying any endpoints that have registered for notification. Primarily, events are used to inform a user input VIA the mouse and keyboard, but their usefulness is not limited to that. Whenever a state change is detected, perhaps when an object has been loaded or INITIALIZED, an event can be fired to ALERT any interested third parties.

An event is a programming construct that reacts to a change in state, notifying any endpoints that have registered for notification. Primarily, events are used to inform a user input via the mouse and keyboard, but their usefulness is not limited to that. Whenever a state change is detected, perhaps when an object has been loaded or initialized, an event can be fired to alert any interested third parties.

Inversion of Control (IOC) and dependency injection are TWO design patterns that are closely related and the container is BASICALLY a chunk of INFRASTRUCTURE code that does both of these patterns for you. IoC pattern is about DELEGATING responsibility for construction and the dependency injection pattern is about providing dependencies to an object that's already been constructed.

Inversion of Control (IoC) and dependency injection are two design patterns that are closely related and the container is basically a chunk of infrastructure code that does both of these patterns for you. IoC pattern is about delegating responsibility for construction and the dependency injection pattern is about providing dependencies to an object that's already been constructed.

You can use the following ways of expressing VALIDATION that are supported by WPF DATA binding:

• Throwing exceptions on a property is SET.
• IMPLEMENTING the IDataErrorInfo interface.
• Implementing INotifyDataErrorInfo.
• Use WPF validation rules.

You can use the following ways of expressing validation that are supported by WPF data binding:

When your application starts accepting data input from end USERS you need to CONSIDER VALIDATING that input. To make sure it CONFORMS to your overall requirements.

When your application starts accepting data input from end users you need to consider validating that input. To make sure it conforms to your overall requirements.

No, if the chunk of content just PROVIDES the structure to render something to the screen and does not support any input or manipulation by the user for that content. It may not need a SEPARATE ViewModel, but it COULD just be a chunk XAML that renders BASED on properties exposed by the parents ViewModel.

No, if the chunk of content just provides the structure to render something to the screen and does not support any input or manipulation by the user for that content. It may not need a separate ViewModel, but it could just be a chunk XAML that renders based on properties exposed by the parents ViewModel.

In between the invoker and the receiver you have an obstruction layer that does not ALLOW the invoker and the receiver to explicitly know about each other. This is typically represented as an interface abstraction EXPOSED to the invoker and a CONCRETE implementation of that interface is CAPABLE of calling the receiver.

In between the invoker and the receiver you have an obstruction layer that does not allow the invoker and the receiver to explicitly know about each other. This is typically represented as an interface abstraction exposed to the invoker and a concrete implementation of that interface is capable of calling the receiver.

There are two main actors, the invoker and the receiver in Command pattern.

Invoker : Invoker is a piece of code which can EXECUTE some imperative logic. Typically, it is a UI element that the user interacts with in the CONTEXT of a UI framework. But it COULD just be ANOTHER chunk of logic code somewhere else in the application.

Receiver : Receiver is the logic that is intended for execution when the invoker fires. In the context of MVVM, the receiver is typically a method in your ViewModel that needs to be CALLED.

There are two main actors, the invoker and the receiver in Command pattern.

Invoker : Invoker is a piece of code which can execute some imperative logic. Typically, it is a UI element that the user interacts with in the context of a UI framework. But it could just be another chunk of logic code somewhere else in the application.

Receiver : Receiver is the logic that is intended for execution when the invoker fires. In the context of MVVM, the receiver is typically a method in your ViewModel that needs to be called.

IMPLICIT data templates can automatically select an appropriate template from the current resource DICTIONARY for an element that uses data binding. They do this based on the TYPE of the data object which is rendered by data binding. FIRST you need to have some element that is binding to a data object.

Implicit data templates can automatically select an appropriate template from the current resource dictionary for an element that uses data binding. They do this based on the type of the data object which is rendered by data binding. First you need to have some element that is binding to a data object.

Data BINDINGS can EITHER be OneWay or TWOWAY to FLOW data BACK and forth between the View and ViewModel.

Data bindings can either be OneWay or TwoWay to flow data back and forth between the View and ViewModel.

Data binding is the key FEATURE that DIFFERENTIATES MVVM from other UI separation patterns LIKE MVC and MVP.

Data binding is the key feature that differentiates MVVM from other UI separation patterns like MVC and MVP.

The main reason of CONSTRUCTING VIEWMODEL in code-behind INSTEAD of XAML is that the view model constructor takes parameters, but XAML parsing can only construct elements if defined in default constructor.

The main reason of constructing ViewModel in code-behind instead of XAML is that the view model constructor takes parameters, but XAML parsing can only construct elements if defined in default constructor.

Another way is that you can do view first construction by simply constructing the view model yourself in the CODE BEHIND of your View by setting the DataContext property there with the instance.

Typically, the DataContext property is set in the constructor method of view, but you could ALSO DEFER the construction until the Load event of the view fires.

using System.Windows.Controls;
namespace MVVMDemo.Views { 
/// <summary> 
/// Interaction logic for StudentView.xaml 
/// </summary> 
public PARTIAL class StudentView : UserControl { 
public StudentView() { 
InitializeComponent(); 
this.DataContext = new MVVMDemo.ViewModel.StudentViewModel(); 
} 
} 
}

Another way is that you can do view first construction by simply constructing the view model yourself in the code behind of your View by setting the DataContext property there with the instance.

Typically, the DataContext property is set in the constructor method of view, but you could also defer the construction until the Load event of the view fires.

using System.Windows.Controls;
namespace MVVMDemo.Views { 
/// <summary> 
/// Interaction logic for StudentView.xaml 
/// </summary> 
public partial class StudentView : UserControl { 
public StudentView() { 
InitializeComponent(); 
this.DataContext = new MVVMDemo.ViewModel.StudentViewModel(); 
} 
} 
}

One way is to simply add your ViewModel as a NESTED ELEMENT in the setter for the DataContext PROPERTY as shown in the following code.

&LT;UserControl.DataContext> 
<viewModel:StudentViewModel/> 
</UserControl.DataContext>

One way is to simply add your ViewModel as a nested element in the setter for the DataContext property as shown in the following code.

<UserControl.DataContext> 
<viewModel:StudentViewModel/> 
</UserControl.DataContext>

There are two ways to construct views. You can USE any ONE of them.

1. View FIRST Construction in XAML
2. View First Construction in Code-behind

There are two ways to construct views. You can use any one of them.

ViewModel is the main point of MVVM application. The primary responsibility of ViewModel is to provide data to the view, so that view can put that data on the screen.

• It also allows the user to interact with data and change the data.
• The other KEY responsibility of ViewModel is to encapsulate the INTERACTION logic for a view, but that does not mean all of the logic of the application should go into ViewModel.
• It should be able to handle the appropriate sequencing of CALLS to make the right thing HAPPEN based on user or any CHANGES on the view.
• ViewModel should also manage any navigation logic like deciding when it is time to navigate to a different view.

ViewModel is the main point of MVVM application. The primary responsibility of ViewModel is to provide data to the view, so that view can put that data on the screen.

The main purpose and responsibilities of views is to define the structure of what the user sees on the SCREEN. The structure CONTAINS static and dynamic parts.

• Static parts are the XAML hierarchy that defines the controls and layout of controls that a view is composed of.
• Dynamic part is like animations or state changes that are defined as part of the View.
• The primary goal of MVVM is that there should be no code behind in the view.
• In view you at least need the constructor and a call to initialize component.
• The event handling, action and data MANIPULATION LOGIC code shouldn’t be in the code behind in View.
• There are also other kinds of code that have to go in the code behind any code that's required to have a reference to UI element. It is inherently view code.

The main purpose and responsibilities of views is to define the structure of what the user sees on the screen. The structure contains static and dynamic parts.

• Static parts are the XAML hierarchy that defines the controls and layout of controls that a view is composed of.
• Dynamic part is like animations or state changes that are defined as part of the View.
• The primary goal of MVVM is that there should be no code behind in the view.
• In view you at least need the constructor and a call to initialize component.
• The event handling, action and data manipulation logic code shouldn’t be in the code behind in View.
• There are also other kinds of code that have to go in the code behind any code that's required to have a reference to UI element. It is inherently view code.

The LAST responsibility is validation which is optional, but you can embed the validation information on the model OBJECTS by USING the WPF data binding validation features VIA INTERFACES like INotifyDataErrorInfo/IDataErrorInfo.

The last responsibility is validation which is optional, but you can embed the validation information on the model objects by using the WPF data binding validation features via interfaces like INotifyDataErrorInfo/IDataErrorInfo.

In general, model is the simplest one to understand. It is the client side data model that supports the views in the APPLICATION.

• It is composed of objects with properties and some VARIABLES to contain data in memory.
• Some of those properties MAY have reference to other model objects and create the object graph which as a whole is the model objects.
• Model objects should raise PROPERTY change NOTIFICATIONS 

In general, model is the simplest one to understand. It is the client side data model that supports the views in the application.

• Some PEOPLE think that for simple UI, MVVM can be an overkill.
• Similarly in bigger cases, it can be HARD to DESIGN the ViewModel.
• Debugging would be a bit difficult when we have complex data bindings.

The key BENEFIT is allowing true separation between the View and Model beyond achieving separation and the efficiency that you gain from having that. What it means in real TERMS is that when your model needs to change, it can be changed EASILY without the view needing to and vice-versa.

 There are three key things that flow out of applying MVVM:

1. Maintainability.
2. TESTABILITY.
3. Extensibility.

The key benefit is allowing true separation between the View and Model beyond achieving separation and the efficiency that you gain from having that. What it means in real terms is that when your model needs to change, it can be changed easily without the view needing to and vice-versa.

 There are three key things that flow out of applying MVVM:

• MODEL − It SIMPLY holds the data and has NOTHING to do with any of the business logic.
• ViewModel − It acts as the link/connection between the Model and ViewModel, and MAKES stuff look pretty.
• View − It simply holds the formatted date and essentially delegates everything to the Model.

The Model, View, VIEWMODEL (MVVM pattern) is all about guiding you in how to organize and structure your code to write MAINTAINABLE, testable and EXTENSIBLE applications.

The Model, View, ViewModel (MVVM pattern) is all about guiding you in how to organize and structure your code to write maintainable, testable and extensible applications.