Showing posts with label MVVM. Show all posts
Showing posts with label MVVM. Show all posts
Tuesday, October 23, 2012
Understanding Basics of UI Design Pattern MVC, MVP and MVVM
5:42 PM
Introduction
This is my first article and I hope you will like it. After reading this article, you will have a good understanding about "Why we need UI design pattern for our application?" and "What are basic differences between different UI patterns (MVC, MVP, MVVP)?”.
In traditional UI development - developer used to create a
View using window or usercontrol or page and then write all logical code (Event handling, initialization and data model, etc.) in code behind and hence they were basically making code as a part of view definition class itself. This approach increased the size of my view class and created a very strong dependency between my UI and data binding logic and business operations. In this situation, no two developers can work simultaneously on the same view and also one developer's changes might break the other code. So everything is in one place is always a bad idea for maintainability, extendibility and testability prospective. So if you look at the big picture, you can feel that all these problems exist because there is a very tight coupling between the following items.- View (UI)
- Model (Data displayed in UI)
- Glue code (Event handling, binding, business logic)
Definition of Glue code is different in each pattern. Although view and model is used with the same definition in all patterns.
In case of MVC it is controller. In case of MVP it is presenter. In case of MVVM it is view model.
If you look at the first two characters in all the above patterns, it remain same i.e. stands for model and view. All these patterns are different but have a common objective that is “Separation of Duties"
In order to understand the entire article, I request readers to first understand the above entity. A fair idea about these will help you to understand this article. If you ever worked on UI module, you can easily relate these entities with your application.
MVC (model view controller), MVP (model view presenter) and MVVM (model view view model) patterns allow us to develop applications with loss coupling and separation of concern which in turn improve testability, maintainability and extendibility with minimum effort.
MVVM pattern is a one of the best solutions to handle such problems for WPF and Silverlight application. During this article, I will compare MVC, MVP and MVVM at the definition level.
MVP & MVC
Before we dig into MVVM, let’s start with some history: There were already many popular design patterns available to make UI development easy and fast. For example, MVP (model view presenter) pattern is one of the very popular patterns among other design patterns available in the market. MVP is a variation of MVC pattern which is being used for so many decades. Simple definition of MVP is that it contains three components: Model, View and presenter. So view is nothing but a UI which displays on the screen for user, the data it displays is the model, and the Presenter hooks the two together (View and model).
The view relies on a Presenter to populate it with model data, react to user input, and provide input validation. For example, if user clicks on save button, corresponding handling is not in code behind, it’s now in presenter. If you wanted to study it in detail, here is the MSDN link.
In the MVC, the Controller is responsible for determining which View is displayed in response to any action including when the application loads. This differs from MVP where actions route through the View to the Presenter. In MVC, every action in the View basically calls to a Controller along with an action. In web application, each action is a call to a URL and for each such call there is a controller available in the application who respond to such call. Once that Controller has completed its processing, it will return the correct View.
In case of MVP, view binds to the Model directly through data binding. In this case, it's the Presenter's job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation. It means while implementing this pattern, we have to write some code in code behind of view in order delegate (register) to the presenter. However, in case of MVC, a view does not directly bind to the Model. The view simply renders, and is completely stateless. In implementations of MVC, the View usually will not have any logic in the code behind. Since controller itself returns view while responding to URL action, there is no need to write any code in view code behind file.
MVC Steps
Step 1: Incoming request directed to Controller.
Step 2: Controller processes request and forms a data Model.
Step 3: Model is passed to View.
Step 4: View transforms Model into appropriate output format.
Step 5: Response is rendered.
So now you have basic understanding of MVC and MVP. Let’s move to MVVM.
MVVM (Model View ViewModel)
The MVVM pattern includes three key parts:
Model(Business rule, data access, model classes)View(User interface (XAML))ViewModel(Agent or middle man between view and model)
Model and View work just like MVC and “ViewModel” is the model of the View.ViewModelacts as an interface betweenmodelandView.ViewModelprovides data binding betweenViewandmodeldata.ViewModelhandles all UI actions by using command.
In MVVM,
ViewModel does not need a reference to a view. The view binds its control value to properties on a ViewModel, which, in turn, exposes data contained in model objects. In simple words, TextBox text property is bound with name property in ViewModel.
In
View:<TextBlock Text="{Binding Name}"/>
In
ViewModel:public string Name
{
get
{
return this.name;
}
set
{
this.name = value;
this.OnPropertyChanged("Name");
}
}
ViewModel reference is set to a DataContext of View in order to set view data binding (glue between view and ViewModel model).
Code behind code of
View:public IViewModel Model
{
get
{
return this.DataContext as IViewModel;
}
set
{
this.DataContext = value;
}
}
If property values in the
ViewModel change, those new values automatically propagate to the view via data binding and via notification. When the user performs some action in the view for example clicking on save button, a command on theViewModel executes to perform the requested action. In this process, it’s the ViewModel which modifies model data, View never modifies it. The view classes have no idea that the model classes exist, while the ViewModel and model are unaware of the view. In fact, the model doesn’t have any idea about ViewModel and view exists.Where to Use What in the .NET World
- Model-View-Controller (MVC) pattern
- ASP.NET MVC 4 Link
- Disconnected Web Based Applications
- Model-View-Presenter (MVP) pattern
- Web Forms/SharePoint, Windows Forms
- Model-View-ViewModel (MVVM) pattern
- Silverlight, WPF Link
- Data binding
Source : http://www.codeproject.com/
Friday, February 17, 2012
Anup Shah on WPF and Silverlight: Architecture...
2:22 PM
![]() |
Above figure shows the overall architecture of WPF. It has three major sections presentation core, presentation framework and milcore. In the same diagram we have shown how other section like direct a...
![]()
Google+ makes sharing on the web more like sharing in real life. Learn more.
Join Google+ |
| You have received this message because Anup Shah shared it with anupshah2it.netspider@blogger.com. Unsubscribe from these emails. | ![]() |
Architecture Of WPF
2:18 PM
********************************************************************************
Can you explain the overall architecture of WPF?
********************************************************************************
User32:- It decides which goes where on the screen.
DirectX: - As said previously WPF uses directX internally. DirectX talks with drivers and renders the content.
Milcore: - Mil stands for media integration library. This section is a unmanaged code because it acts like a bridge between WPF managed and DirectX / User32 unmanaged API.
Presentation core ;- This is a low level API exposed by WPF providing features for 2D , 3D , geometry etc.
Presentation framework:- This section has high level features like application controls , layouts . Content etc which helps you to build up your application
Wednesday, February 15, 2012
Ques.
11:44 AM
************************************************************
Difference between DataSet and DataReader
************************************************************
DataReader
===========
DataReader is like a forward only recordset. It fetches one row at a time so very less network cost compare to DataSet(Fethces all the rows at a time). DataReader is readonly so we can't do any transaction on them. DataReader will be the best choice where we need to show the data to the user which requires no transaction. As DataReader is forward only so we can't fetch data randomly. .NET Data Providers optimizes the datareader to handle huge amount of data.
DataSet
=======
DataSet is an in memory representation of a collection of Database objects including tables of a relational database schemas.
DataSet is always a bulky object that requires a lot of memory space compare to DataReader. We can say that the DataSet is a small database because it stores the schema and data in the application memory area. DataSet fetches all data from the datasource at a time to its memory area. So we can traverse through the object to get the required data like querying database.
DataReader is like a forward only recordset. It fetches one row at a time so very less network cost compare to DataSet(Fethces all the rows at a time). DataReader is readonly so we can't do any transaction on them. DataReader will be the best choice where we need to show the data to the user which requires no transaction. As DataReader is forward only so we can't fetch data randomly. .NET Data Providers optimizes the datareader to handle huge amount of data.
DataSet
=======
DataSet is an in memory representation of a collection of Database objects including tables of a relational database schemas.
DataSet is always a bulky object that requires a lot of memory space compare to DataReader. We can say that the DataSet is a small database because it stores the schema and data in the application memory area. DataSet fetches all data from the datasource at a time to its memory area. So we can traverse through the object to get the required data like querying database.
************************************************************
What is the difference between app.config, web.config and machine.config ?
************************************************************
In this .NET Interview questions interviewer expects two things. First the importance of configuration and second in which scenarios are the above file applicable. So lets answer the question in two parts.
What is the difference between app.config, web.config and machine.config ?
************************************************************
In this .NET Interview questions interviewer expects two things. First the importance of configuration and second in which scenarios are the above file applicable. So lets answer the question in two parts.
### The importance of config files ###
App.config, web.config and machine.config are files which store configuration data in XML
App.config, web.config and machine.config are files which store configuration data in XML
format. We need configuration data at application level or at machine/server level.
### Scenarios in which the above config files are used ###
Machine.config file stores configuration information at system level. It can contain configuration information like timeout in ASP.NET application, requestLimit, memoryLimit, and ClientConnectedCheck etc.
Machine.config file stores configuration information at system level. It can contain configuration information like timeout in ASP.NET application, requestLimit, memoryLimit, and ClientConnectedCheck etc.
Generally we have two kinds of application web application and windows application. Web.config file stores configuration data for web applications and app.config file store configuration information for windows application.
Application level configuration data can be like connection strings,security etc.
************************************************************
What is Encapsulation?
***********************************************************
- Encapsulation is one of the fundamental principles of object-oriented programming.
- Encapsulation is a process of hiding all the internal details of an object from the outside world
- Encapsulation is the ability to hide its data and methods from outside the world and only expose data and methods that are required
- Encapsulation is a protective barrier that prevents the code and data being randomly accessed by other code or by outside the class
- Encapsulation gives us maintainability, flexibility and extensibility to our code.
- Encapsulation makes implementation inaccessible to other parts of the program and protect from whatever actions might be taken outside the function or class.
- Encapsulation provides a way to protect data from accidental corruption
- Encapsulation hides information within an object
- Encapsulation is the technique or process of making the fields in a class private and providing access to the fields using public methods
- Encapsulation gives you the ability to validate the values before the object user change or obtain the value
- Encapsulation allows us to create a "black box" and protects an objects internal state from corruption by its clients.
Monday, February 6, 2012
The Model-View-ViewModel Pattern
5:34 PM
How the MVVM pattern became convenient


WPF has a very powerful databinding feature, that provides an easy one-way or two-way synchronization of properties. You can directly bind two WPF elements together, but the common use of databinding is to bind some kind of data to the view. This is done by using the
DataContext property. Since the DataContext property is marked as inherited, it can be set on the root element of a view and it's value is inherited to all subjacent elements of the view.
One big limitation of using the
DataContext property as data source is, that there is only one of it. But in a real life project you usually have more than one data object per view. So what can we do? The most obvious approach is to aggreate all data objects into one single object that exposes the aggregated data as properties and that can be bound to theDataContext. This object is called the view model.Separation of logic and presentation
The MVVM pattern is so far only a convenient way to bind data to the view. But what about user actions, how are they handeld? The classic approach, known from WinForms is to register an event handler, that is implemented in the code-behind file of the view. Doing this has some disadvantages:
- Having event handlers in the code-behind is bad for testing, since you cannot mock away the view.
- Changing the design of the view often also requires changes in the code, since every element has it's different event handlers.
- The logic is tightly bound to the view. It's not possible to reuse the logic in an other view
Commands. Commands can be bound like data and are supported by many elements as buttons, togglebuttons, menuitems, checkboxes and inputbindings. The goal here is not to have any line of logic in the code-behind of a view. This brings you the following advantages- The view-model can easily be tested by using standard unit-tests (instead of UI-testing)
- The view can be redesigned without changing the viewmodel, because the interface stays the same.
- The view-model can even be reused, in sone special cases (this is usually not recommended)
What's the difference between MVVM, MVP and MVC?
There is always some confusion about the differences between model-view-presenter, model-view-controller an MVVM pattern. So I try to define and distinguish them a bit more clearly.
MVC - Model-View-Controller
The MVC pattern consists of one controller that directly gets all user input. Depending of the kind of input, he shows up a different view or modifies the data in the model. The model and the view are created by the controller. The view only knows about the model, but the model does not know about any other objects. The pattern was often used in good old MFC and now in ASP.NET MVC
MVP - Model-View-Presenter
In the MVP pattern, the view gets the user input and forwards it to the presenter. The presenter than modifies the view or the model depending on the type of user action. The view and the presenter are tightly coupled. There is a bidirectional one-to-one relation between them. The model does not know about the presenter. The view itself is passive, thats why it's called presenter pattern, since the presenter pushes the data into the view. This pattern is often seen in WinForms and early WPF applications.
MVVM - Model-View-ViewModel
The model-view-viewmodel is a typically WPF pattern. It consists of a view, that gets all the user input and forwards it to the viewmodel, typically by using commands. The view actively pulls the data from the viewmodel by using databinding. The model does not know about the view model.
Subscribe to:
Posts (Atom)


