Our first step is to understand the three-tier architecture and issues and then see how MVVM solves these problems.
Now, the feeling and the fact are totally different two things. When you see a block diagram of the three-tier architecture, you feel that the responsibilities of each layer are well-distributed. But when you actually write the code, you'll find that some layers are forced to do extra things that shouldn't have been done (violating the solid principle s).
This extra work is the code between Ui-model and Model-data access. Let's call this Code "GLUE" code. There are two main types of logic that can cause "GLUE" code (perhaps I know not enough, others can find out for themselves):
1. Mapping logic (binding logic): Each layer communicates with other layers through attributes, methods, and collections. For example, a textbox called "Txtcustomername" in the UI layer is associated with the "CustomerName" property of the Customer class.
Txtcustomername.text=custobj. CustomerName; // Mapping Code
Now who owns the binding logic code above, the UI or the model layer? Developers typically push this code to the UI layer.
2. conversion Logic : The data format is not the same on different layers. For example, a "person" class has a property called "Gender" and contains "F" and "M", but in the UI layer, we want to see a checkbox, "checked" (true) for male, "unchecked" (false) represents female. The following is a sample code for the transformation.
if (obj. gender== "M")//Transformation Codechkmale.ischecked=true;
Else
Chkmale.ischecked=false;
Most developers write such "GLUE" code in the UI layer. In order to put these code details can generally be found in the code behind the answer, such as. cs file. So if you first "XAML" and then "Xaml.cs" there will be glue code, "aspx" and then "Aspx.cs" there will be glue code and so on.
Now there is a question: is the glue code the responsibility of the UI? Let's look at an example of a WPF program and the details of the bonded code.
Here is a simple "Customer" model class with 3 properties "CustomerName", "Amount" and "Married" fields.
But this model is shown in the UI layer as shown below. So you can see that it contains all the fields of the model and also adds some extra stuff, look at the color label and married check box.
Here is a simple chart, the field on the left of the model, and the field to the right of the UI. The middle is a description of the logic of the mapping and transformation.
You can see the first 2 fields we don't have any conversion logic, they only have the mapping logic. The other 2 field mappings and transformations have logic.
The logic of transformations and mappings is usually in the background code, such as "XAML.CS". Here is the background code of customer screen above, you can see the mapping code, color judgment code and gender format conversion code. I added a comment to the code so you can see which is the mapping code, which is the conversion code.
Now there are a few questions around the glue code:
1. Violation of SRP: Is this glue code the responsibility of the UI? If you know what happened at the time, the UI code would have to change when the value of amout changed. So why do I need to change my UI code when the data changes? It seems that you can smell the bad code. The UI should be changed only when I change styles,colors,positoning and so on.
2. reusability : What do I do if I want to use the same color logic and gender conversion on an editorial interface like this? I'm going to copy and paste to create duplicate code?
If I want to go one step ahead, use the glue code on different UI technologies, like Mvc,windows form or mobile.
However, because of the close relationship between the specification and UI technology behind the UI, it is virtually impossible to reuse across different UI technologies.
For example, the following code is inherited from the "Window" class. The "Window" class and the WPF UI technology are closely related. So, if we want to use this logic in Web applications or MVC, how do we create an object of this class and consume it.
Public Partial class mainwindow:window{
// behind Code is here
}
How do we reuse the backend code? How are we going to abide by the SRP?
WPF MVVM Architecture Step by Step (2) (simple three-tier architecture example and glue code glue)