Aug
10
Silverlight – View Model ”; Previous Next In this chapter, we will be looking at an important technique in Silverlight”s software development, the use of View Models. The view model is a key piece, which introduces a technique called separated presentation by keeping the view separate from the model. View Models offer one-way of achieving separated presentation, and we will see how they exploit Silverlight”s data binding to reduce the amount of code needed in your user interface. UI Development Challenges View Models are designed to solve certain problems that crop up frequently when developing user interface software. Perhaps the most important one is that user interface code is often difficult to inextricably test, especially with automated unit tests. There are also code quality problems that can affect the ongoing flexibility and maintainability of your code. If you follow the path of least resistance that Visual Studio”s design tools lead you down, you can end up putting far too much code into the code behind. It is very common to see large amounts of application functionality are added into the code behind. Few developers would actually plan to put business logic into a user interface class, but because that is where Visual Studio puts your event handlers, it becomes an all too convenient place to get the things done. It is widely accepted that software is easier to develop and maintain if classes have well-defined, and reasonably narrow responsibilities. The code behind”s job is to interact directly with the objects that make up the user interface where it is necessary. As soon as you start putting code that makes decisions about how your application behaves in there which tends to lead to problems. Not only can application logic flow into code that”s supposed to be concerned with the user interface, some developers start to rely on controls, and other user interface objects to hold important application state. The model simply holds the data, the view simply holds the formatted date, and the controller (ViewModel) acts as the liaison between the two. The controller might take input from the view and place it on the model and vice versa. Separated Presentation To avoid the problems caused by putting application logic in the code behind or XAML, it is best to use a technique known as separated presentation. Having XAML and code behind with the minimum required for working with user interface objects directly, a user interface classes also contain code for complex interaction behaviors, application logic, and everything else as shown below on left side. Important features of Seperated Presentation − With separated presentation, the user interface class is much simpler. It has XAML of course, but the code behind does as little as is practical. The application logic belongs in a separate class, which is often referred to as the model. Many developers attempt to use data binding to connect elements in the XAML directly to properties in the model. The problem is the model is entirely concerned with matters of what the application does, and not with how the user interacts with the application. Most user interfaces have some state that does not belong in the application model. For example, if your user interface uses a drag and drop, something needs to keep track of things like where the item being dragged is right now, how its appearance should change as it moves over possible drop targets, and how those drop targets might also change as the item is dragged over them. This sort of state can get surprisingly complex, and needs to be thoroughly tested. In practice, you normally want some other class sitting between the user interface and the model. This has two important roles. First, it adapts your application model for a particular user interface view. Second, it is where any nontrivial interaction logic lives, and by that, I mean code required to get your user interface to behave in the way you want. Model / View / ViewModel View Model is an example of the separated presentation approach, but let us be clear about exactly what sort of thing we have in each layer. There are three layers − Model View ViewModel Model This is a classic object model comprising of ordinary C# classes that has no direct relationship with the user interface. You would typically expect your Model codes to be able to compile without references to any user interface libraries. In fact, you would probably be able to take the exact same source code and compile it into a Silverlight application, an ordinary .NET Console application, or even server-side web code. The types in the Model should represent the concepts your application works with. View A View is normally a UserControl, it might be your MainPage, or it might just be some part of your page. In most Silverlight applications, it is a good idea to split your user interface up into small pieces defining a UserControl, or View for each piece. Silverlight applications are not unique in this respect. Something that is obviously Silverlight specific is the View. The more fine-grained your user interface is, the better things tend to be. Not only are you less likely to trip over other developers working on the same files, keeping things small and simple naturally discourages the shortcuts that lead to spaghetti-like code. For example, it is very common to define a View to represent an individual item in a List. ViewModel Finally, for each View, you write a ViewModel. So, this is one of the important features of a ViewModel class. It exists to serve a particular View. The ViewModel is specialized for a particular way of presenting things, such as a particular data item as it appears in Lists. This is why it is called a ViewModel; it adapts the underlying Model especially for a particular View. Like the Model, the ViewModel is also an ordinary C# class. It does not need to derive from any particular type.