MVVM - Mystery Solved


The MVVM design pattern is a pattern that separates concerns. By that, it means that the three or more tiers of a data driven application are separated. Data, Business (Logic), and Presentation (UI).

The MVVM design is not set in stone. But knowing how it works will save a lot of time when it comes to updating the application by adding new technologies, or updating the data structure itself. For example, you want to update your application to run SQL Server and Oracle. While these two databases are very different, and may even contains different data structures, the MVVM design allows you to import the data, and have it processed the same way no matter where it comes from. In addition, the design allows you to change a part of the application without breaking the integrity of the other parts. In turn you can easily update your applicaiton without having to start from scratch.

The Data Layer

Data is the heart of your application. The data can be one, several, or even many libraries. Each having their own connection to outside data sources, such as files, databases, web services, and RSS feeds.

The basic rule is to have a library for each type of data source. For example, one for an SQL Server, another for Oracle, and another for a web service. You get the idea. Keeping the data connections separate will ensure that the application will remain intact as you add and remove different connections libraries as your application grows and matures.

The naming conventions for data sources are typically <My Solution>.Data.<Data Source>. For example BusinessAccountant.Data.SQLServer.

The Models

Models can be found in it's own space, the Data Layer, or even the Business Layer. This space usually consists of Data Models that encapsulates the data for processing in the Business Layer. The Models Namespace also provides Interfaces that instructs the data sources in how to provide the data. More or less the interface allows the Business Layer says to the data source, "I don't care what your data structure looks like, I needs the data in this structure!"

The naming conventions for the Models Library is typically <My Application>.Data.Models.

The naming conventions for the Interfaces are typically named by the model. For example for the Customer model I would create an ICustomerDataSource interface. Then when I create the data source for the customer, I would implement the ICustomerDataSource. Inside the Interfaces is where you define your methods for Create, Retrieve, Update, and Delete (CRUD).

Data Source Interface Example

Public Interface ICustomerDataSource

    ' A synchronous method to add a customer,
    ' and have it return the updated customer
    ' model after it is added to the database.
    Function AddCustomer(c As customer) As Customer

    ' A synchronous method to add a customer,
    ' and have it return the number of records
    ' that were changed by adding the customer to
    ' the database
    Function AddCustomer(c As customer) As Integer

    ' An asynchronous method to add a customer.
    Sub AddCustomer(c As customer)

    ' An Event that will be fired when the 
    ' AddCustomer asynchronous method is 
    ' complete. The event handler will
    ' notify the business layer which library
    ' complete the update 
    Event AddCustomerComplete As EventHandler

End Interface

Business Layer

The Busainess Layer is where the data from the model is processed and pushed to the view. There are two types of designs that are used to push data from the Business Layer to the Presentation Layer. Model Injection and ViewModel Injection.

Model Injection involves having the model process all data validation and change tracking. The ViewModels job is to retrieve the Model from the data source and simply push it to the View. The ViewModel also pushes that changes Model back to the data source for updates. The Model Injection method is carried over from Model View Controller method.

ViewModel Injection involves placing all the data validation and change tracking inside the ViewModel. The model will only hold data and structure. Think of it as an XML document. You can place data inside it, but manipulation or validation is done outside the data structure. When the ViewModel retrieves the Model, it will encaspulate the data in the Model into the ViewModels own properties, and exposes the properties to the View.

The Presentation Layer

The Presentation Layer only allows output and input of data. More or less it is the gateway from the user to the inner gears of the application. Most programmers used to MVC get confused here since there is a separation of ViewModel and View. The Code-Behind issue arises. There is no rule that the Code-Behind has to be blank. It simply means that if it is not View related, it doesn't belong in the View. So, if you have a drag-and-drop... guess what? It is a View related issue, and not data related, so it goes in the Code-Behind.

The main idea of MVVM and the View is to keep only View related issues separated from data related issues. This not only cleans up the code behind, it also separates that data itself from the input and output of the data.

Wrapping Up

The MVVM is a great structure for Team Builds and Data-Driven applications. It is not recommended for every type of application out there - especially if it is a small one. Another thing to keep in mind that it is not an end-all for all Data-Driven applications. Always think about if the application will even need to connect to different data sources, or if the application will be used on multiple devices (web, desktop, windows phone). If there is a chance that the application will do either of these, then it would be a good idea to use MVVM.

More by this Author


No comments yet.

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.

    Click to Rate This Article