Now, with the release of Silverlight 2, the number of applications based on this technology is increasing, but at the same time, certain growth challenges have emerged. The basic structure supported by the Silverlight 2 pattern involves tight integration of the user interface with the operational data. While this tight integration is useful for learning the technology, it has become an obstacle for testing, code optimization, and support.
The problem
At the heart of the problem is the tight coupling that results from mixing application tiers. When one tier is well aware of another tier performing a task, your application has a tight coupling. Take a simple data entry application that allows you to query homes for sale in a particular city. In a tightly bound application, you can define the query to perform the search in the UI button handler. When the schema or semantics of the search changes, both the data layer and the UI layer must be updated.
This leads to the problem of code complexity and quality. Every time the data layer changes, the application must be synchronized and tested to ensure that the changes are not major. If everything is tightly coupled, any move in one part of the application can cause ripple changes in the rest of the code. When creating something simple in Silverlight2, such as a video player or a mini menu application, tightly coupled application components are unlikely to be a problem. However, as the size of the project increases, the difficulties will be felt more and more.
The other side of the problem is unit testing. When an application is tightly coupled, only its functional (or UI) testing can be done. Again, this is not a problem in a small project, but as the size and complexity of the project increases, the ability to test application tiers separately becomes very important. Remember that unit testing is not just about verifying that a module works when it is used in the system, but that it continues to work in the system. Having unit tests for parts of the system adds confidence that when the system changes, problems will be discovered earlier in the process rather than later (which will happen with functional testing). Regression testing (e.g., running unit tests on the system on each build), which becomes key to ensuring that small changes added to the system do not cause cascading bugs.
Building an application by defining different tiers may seem to some developers like a case of over-development. The fact is that when you create an application with or without tiers, you are working with an n-tiered platform, and the application will have tiers. But without formal planning, you’ll end up with a very tightly bound system (and with the problems described above) or an application with a mass of unstructured code that will be a big problem to maintain.
It is easy to assume that creating an application with separate layers and tiers requires a lot of infrastructure to make it work well, but in fact simple tiering is quite easy to implement. (It is possible to design more complex application tiering using control inversion techniques, but that presents a different problem not covered in this article.)
Application tiering in Silverlight 2
Silverlight 2 does not require you to invent something new to define a way to tier your application. Several well-known patterns can be used for design.
There is a lot of talk now about the MVC (model-view-controller) pattern. In the MVC pattern, the model is the data, the view is the user interface, and the controller is the programmatic interface between the visualization, the model, and the user input. However, this pattern does not work well with declarative user interfaces such as Windows Presentation Foundation (WPF) or Silverlight because the XAML used by these technologies can define a specific interface between the input and the view (as data binding, triggers, and states can be declared in XAML).
“Model-View-Presenter-Presenter” (MVP) is another common pattern for tiering applications. In the MVP pattern, the presenter is responsible for setting up and managing state for the presentation. Like MVC, the MVP pattern is not well suited for the Silverlight 2 model because XAML may contain declarative data binding, triggers, and state management. What to do.
Fortunately for Silverlight 2, the WPF community has rallied around a pattern called the Model-View-View-Model (MVVM). This pattern is an adaptation of the MVC and MVP patterns, in which the view model provides the data model and behavior for the view, but allows the view to perform declarative binding to the view model. The view becomes a mixture of XAML and C# (like Silverlight 2 controls), the model represents the data available to the application, and the view model prepares the model for its binding to the view.