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.
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
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.
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
The core of the MVVM design contains abstract base classes that will be used throughout your application. The core will always contain the ObserverableObject. This class will implement the INotifyPropertyChanged...
Models are the data layer of an MVVM application. The models are used to store data in objects (classes) where it can be serialized for transmission to a remote location, or it can be formatted to be stored in a...
No comments yet.