System Architect-Basic to enterprise application architecture-performance Layer

I, Preface

Recently, it may be due to holidays.ArticleI am sorry for the slow speed. It is really difficult to write this series. Thanks for your support and attention, I did get your support after the release.

Holding and recognizing have given me more motivation. Some of the content released earlier may not be wide enough for the content explained at each layer. Of course, this is related to my personal experience, please provide your valuable comments and suggestions.

From the beginning of this article, I will adopt a more standardized format, a more rigorous attitude towards knowledge, and a more accurate expression. I will finish the next series of articles, after talking with many friends in the group

PDF e-books, which is easy to read. Thank you for your support. I will share the content of each article in the future in pdf format, if you have any need, you can download it.

The writing level is limited, so there are still many shortcomings in the depth of writing and the format of writing, and I hope you can point out more.

II, Opening

In this article, we will describe the presentation layer in the system architecture hierarchy to analyze the architecture and design mode of the presentation layer. Of course, we will analyze and explain the current popular presentation layer mode, mainly around the MVC model

And analyzes the application design of the current MVC pattern in different UI layers. Due to my limited level, in addition, the actual project may have insufficient understanding and experience

Some analyses are incorrect. Please submit them again. In our previous writing practices, let's take a look at the main content of this article.

This article will explain the content of the presentation layer from the above two points.

III, Contents

1. Preface

2. Summary

3. Outline

4. Presentation layer mode

4.1. responsibilities at the performance Layer

4.2 UI Layer and presentation layer Logic

4.2.1 responsibilities of the user interface

4.2.2 misunderstandings in the presentation layer

4.3 introduction and evolution of the MVC model

4.3.1. MVC Mode

4.3.2 MVP Mode

4.3.3 comparison and summary of MVC and MVP Modes

5. Conclusion

6. Series progress

7. next announcement

IV, Presentation layer mode 4.1. responsibilities at the performance Layer

We know any applicationProgramIf we want to better interact with customers, we generally provide a user interface to complete interaction with users. Of course, as we have mentioned earlier, the service layer and the business environment

The logic layer is used to better serve the performance Layer. Generally, we do not pay special attention to the performance Layer. However, the performance layer is equally important. In fact, when we focus on various layers

The importance of each layer varies depending on our hobbies, attitudes, or professional skills, but a good system, we must pay enough attention to each layer.

During the presentation layer, we usually focus on the following components: first, the user interface. That is, the user interface that the customer can see is short for the UI, and another part is the component that interacts with user behavior, usually

This is called the presentation layer logic. All operations of a user are supported by the presentation layer logic. The presentation logic layer is responsible for interaction between other layers and the UI Layer.

Based on the layered design described above, we know that the presentation layer logic mainly interacts with the service layer or business logic layer. The specific relationship is as follows:

By knowing the location of the presentation logic layer, we can say that how to organize the relationship between the user interface and the presentation layer logic and other layers is the key to determining the design quality. It can also be said that the presentation layer logic determines the user

Interaction with the system.

Let's take a look at the responsibilities of the performance layer.

We generally regard the following responsibilities as the responsibilities of the performance Layer. Do you share the same view?

As shown in the figure, verification, formatting, and adding styles should belong to the UI Layer components instead of the presentation layer,

As an architect, you must consider more comprehensively and at a higher level, such as the following aspects:

Only by better considering these factors can we determine the architecture of the performance layer.

A simple analysis.

1. UI independence:

The UI independence here refers to the implementation technology independent of the UI Layer, whether it is web or winform, other WPF, WP, or any other UI representation. We know this performance.

The layer design is ideal. We just want to improve reusability as much as possible. We hope that although different UIS use different implementation technologies, these UIS can share the presentation layer logic, at this time, we can do very well.

Good reusability.

We need to know what we propose hereCodeThe purpose of reuse is to achieve logic reuse at the presentation layer as much as possible, but in some cases we cannot do it. For example, Silverlight and WPF are different because they use different

CLR, so we can only say that code can be reused. We need to compile them separately.

2. Testability

All layers must be tested, because only the test can determine whether the function can meet the requirements well. However, the performance layer test is more complex than other layers, because the performance Layer needs to consider

There are many factors, which determine the difficulty of testing. Therefore, better testing is the basic requirement of our architecture design.

Generally, the processing process at the presentation layer is as follows:

The figure above roughly describes the basic process in the presentation layer. We will describe it in combination with the graphics:

Action will trigger corresponding action events. These events will be processed by a special controller. The controller sends the results returned by the processing function to the specified processing function, feedback to the user interface.

Through the above process, we know that we must simulate user behavior during the test, and how to ensure that user behavior events can be correctly handled are the content we must test. If we set all

The content is written in the presentation layer, so I think it may not be so easy to test. If our user interface and the presentation layer logic are written in a page, it may not be easy to test. Fortunately, APS. NET through code

The back-end technology separates the logic code of the design layer from the presentation layer. Of course, we have put forward a point of view on the implementation of the architecture design before, that is, the separation of power points, the functional points of attention are separated, and a higher pumping

As shown in the following figure.

3. Data Model independent

We mentioned the data transmission object in the service layer and business logic layer, and used this object as the carrier for communication with the presentation layer. After using the data transmission object, then we can make the presentation layer independent of me.

Our data models, but we have also said that data transmission objects bring more classes and more engineering files to projects, so this will bring additional work to our development work. Because different performance layers require

The corresponding data transmission objects are consistent with those described above. Therefore, whether to use data transmission objects in the project depends on the project's needs.

4. Independent of graphical elements

The graphical elements here refer to the set of controls and tools provided by development tools. Through these graphical elements, we can design interfaces for interaction with users, we hope that our performance layer can be controlled differently.

It can be displayed in different ways. We also hope that any modifications to the graphic elements will not affect the presentation layer logic. For example, we usually design templates in the blog, it is actually a good example.

Sub-, when we select different templates, our blog pages will change in terms of skin, style, and topic, but it does not affect our performance layer.

4.2 UI Layer and presentation layer Logic 4.2.1 responsibilities of the user interface

Next, let's take a look at the relevant responsibilities of the UI Layer. We know that during the system design process, the general architect will not directly participate in the design of the user interface, architects focus more on system availability and accessibility

. We believe that the main functions of the UI Layer include the following:

Let's talk about it separately.

1. Data Display

We all know that the UI Layer is the only portal for users to use the system. First, some information in the system must be displayed on the user interface, which may include common information, prompt information, and related data in the system.

Information, and a good design UI can display data well. The user interface must support localization and globalization features.

2. Friendly Interaction

Interaction is reflected in the user's use of system functions, so that there will be such an operation, the user enters the corresponding data, usually a good UI Layer, will provide users with a user-friendly input page, and will root

Return the desired result based on the user input. No matter what the UI Layer is, a good user interaction page is the most important part of the system. How do we verify the security of the input data?

Must be paid attention.

3. overall appearance

System functions are provided to users through the user interface as a unified portal. Therefore, in general, we must have a refined user interface when designing the UI. The purpose of the software is to capture users, available for use

Users have a good user experience, and different designs are carried out according to the user group of the software. If the software is provided to the public, we must meet the requirements of exquisite user interfaces, if it is provided to the Enterprise

So we can focus on functions rather than visual effects, of course not to say that we do not pay attention to the UI, but not so much attention.

4.2.2 misunderstandings in the presentation layer

Let's take a look at the mistakes we may encounter during the design and implementation of the presentation layer.

Let's take a look at the explanation of each misunderstanding.

1. Over-reliance on tools

Since Visual Studio development tools are available, it provides a large number of controls to facilitate the development of simple applications, we usually set the UI Layer by dragging the control.

. We use some controls with events to complete interaction with other layers. We can directly process the logic in the event, which is convenient and fast. This also makes our development highly efficient. Of course this is development

There is no problem when we do this for simple applications. However, when we develop large enterprise-level applications, this method may not be an ideal choice. Why? We are not saying no

Use the controls provided by development tools to divide responsibilities. For example, use the designer to design the interface, and other code is written by hand, instead of some control provided by development tools

Such as the data source binding control provided by Visio Studio, and how to better abstract the code in the event is a problem that needs to be considered here.

2. Presentation Layer Boundary

What are the responsibilities of the presentation layer first? What is it mainly responsible? We know that the UI Layer in the presentation layer is a very weak layer. The UI Layer should only be responsible for interacting with users, and the presentation layer logic should be responsible for coordinating the number

What functions should the presentation logic layer have. As we mentioned earlier in the business logic layer, sometimes we can accept the business logic in the presentation layer.

See the specific system requirements.

Sometimes we love to show all the functions in the business logic layer to the logic layer. This is also true for many of my own projects, because the code in my current project is also full of people, we have said that this is not

But when the system has a certain scale, the presentation logic layer will become an all-encompassing and all-encompassing container, making it difficult to maintain and test.

Through the above analysis, we know that we still need to decide whether to write some business logic in the presentation logic layer based on the actual needs of the system. For large enterprise-level projects, we must consider these questions.

Because a good design can provide testing and maintainability, we also have high requirements on the presentation logic layer. We hope to achieve this through Soc. We generally achieve this through layering, separation of functions by Layer

Point. By separating the focus, we can provide refactoring of the presentation logic layer, reminding us to better design the structure and code structure and improve reusability.

3. wugwyw

What do you think it means? Forgive me for selling a token here, which means (what-user-get-is-what-you-want) what users get is what they want.

When we use graphical interface design tools, in order to better provide development efficiency, many development tools now provide the interface preview function, which is basically WYSIWYG, but not all, such

The Web Development preview provided by Visio Studio, but sometimes we need to do something on the presentation layer by ourselves, so we will control the display of the UI Layer through CSS on the interface, I will explain this here

This means that sometimes we need to write more code to provide better functions to meet user needs.

4.3 introduction and evolution of the MVC model

Starting from this section, we will begin to explain the patterns in the presentation layer. We will mainly explain the origins and development processes of the MVC pattern.

4.2.2. MVC mode (Model-View-Controller)

The MVC model originated in the 1980s s and has a history of 30 years. Today, we may not be able to use the original definition to design the presentation layer, but now we use

The MVC pattern has evolved from the original MVC pattern to meet the current software development requirements. The MVC pattern we may refer to here is not the original definition, including the MVP pattern described later.

Here we need to know what types are available in the presentation layer and what types may be evolved from each type. This gives us a rough structure of the presentation layer pattern, this is of great help to the design of the presentation layer,

Let's take a look:

We will explain in detail these models and applications. This section will explain in detail the evolution of MVC and its original

The model2 mode evolved from the MVC mode officially implements ASP. net mvc.

When we first developed the presentation layer, I think we put the logic and view of the presentation layer in a file, which can be seen as a functional autonomy view. The user interacts with the view. The view captures user input.

Information, and internal processing, and then update yourself or jump to another view. Such an organizational structure is not only difficult to maintain, but is more difficult to test. Therefore, it makes everyone more eager to have a good model, from the complex performance.

Separated from the layer, thus the MVC mode is proposed.

The presentation of the MVC model disconnects us from the design method of view autonomy. The internal processing of an autonomous view may include the business layer, data access layer, or service layer, of course, there is also its own design layer. MVC

Mode, let us separate the functions of the autonomous view, divide the autonomous view into a view layer, a control layer, and a model form to separate the focus, through the separation of focus, to reduce the complexity of the system, and then provide

Better design of the system.

So some people call the MVC model a model. Is MVC a model or a model? Let's take a look at the definition of models and models? Maybe we can better understand MVC.

In the software field, a pattern refers to a proven solution to a specific type of problem.

Model refers to a solution to a category of similar problems, and generally refers to a category of similar models.

Through the above explanation, we know that MVC is a pattern.

Let's take a look at the differences between the autonomous view and the MVC structure. We know that the MVC mode separates the functions of the autonomous view, and the separation can be relatively independent components, and completes the presentation layer through the interaction of these components

.

In this case, the autonomous view places all functions in one container, while the MVC mode focuses on the functional points.

Separation, through the feature separation implementation, we divide the presentation layer into three components with different roles, through the cooperation between these components to complete the work of the autonomous view.

What is the original definition of MVC? Let's take a look at it. In the original definition of MVC, we use the model as the entry to the business logic. In the model, we can see the state of the program. We need

Data is displayed in the view and the view receives user actions, and then responds to user actions through the model. The model processes the operation requests sent from the Controller. Generally, these requests are

The status has changed.

However, with the development of the presentation layer model, the definition of MVC is no longer as defined in the original definition. The current model is only responsible for maintaining the state of the application, most of the work is done in views and controllers.

Controller becomes a more core component. Our existing MVC model may use more data objects in the business, domain objects built specifically for domain models, or data transmission pairs.

Image. Of course we decided based on the needs of our projects at work. Let's take a look at the call relationship between the simple components in the MVC mode.

Of course, don't be surprised. This is the most primitive MVC processing process. In today's popular MVC frameworks, the process is not handled in this way, but by understanding the original definition, we will be more in-depth.

It is helpful to understand MVC. MVC was proposed at the time, not for the web, but the development of the MVC model is popular on the Web. For example, the ASP. net mvc framework provided by Microsoft

Line many optimizations and modifications. The principles of this mode will be described later.

Let's take a closer look at the possible code of the view in MVC: In general, the view layer displays the relevant information to the user through some control elements designed on the interface layer, and the user interacts with the system through the interface layer, then we

How to capture user operations in the view? The view uses some column controls to capture user actions, such as input boxes or buttons. The front-end of the view is bound to the background code through delegation. We know that

Soft processing. net has a lot of skills in the presentation layer, in which the view and background code are put in different class files to complete separation, so that, the user-initiated actions in the view will be captured in the Post-code class, and then

The corresponding processing.

Let's take a look at the possible code of the controller.

 
/// <Summary> /// controller class /// </Summary> public class controller {public void action (actiontype) {}}/// <summary> // action completed by the Controller /// </Summary> Public Enum actiontype {add, delete, query, update}
 

Possible code in the View:

 
Private void button#click (Object sender, routedeventargs e) {controller = new controller (); controller. Action (actiontype. Add );}
 

The Controller in the code can be a view of any specific technology. The controller will provide a special method for each possible operation in the view, each action supporting user operations corresponds to a related action.

Processing Service. The view is responsible for data presentation, and the Controller is responsible for updating the model. If the model changes, the observer mode will be used to notify the view of changes in its status, and the view will decide whether to change the model.

It is reflected in the view. If an update is required, the view reads the latest data from the model.

The model in MVC lists several possibilities. If the model here is the business logic layer, We will directly call the methods in the business logic object to update the model status.

If the model in MVC is a data transmission object, then the Controller may access the public method corresponding to the data transmission object through the service layer interface abstracted by the business logic layer.

Create a model. If the model here is a business model, the Controller only performs the routing function. First, it needs to parse the sender of the action and then resolve the action to the business model for processing and forwarding.

After the process is completed, the business model is automatically completed.

The Controller is sometimes responsible for selecting the jump function for rendering the view. If you need to jump, the Controller will create a new view, Controller, and model.

Sometimes we may want to complete redirection through global configuration, such as configuration through an XML file, similar to a workflow. How can we do this by configuring the targeted page?

What about it? We need to provide a service layer to complete the targeting, for example, through a common class to complete such operations.

<? XML version = "1.0" encoding = "UTF-8"?> <Configuration> <Route> <URLs> <URL key = "key" value = "value. aspx"> </URL> </URLs> </route> </configuration>
 

The specific routing code is as follows:

 
Public class route {public route () {}/// <summary> /// redirect service /// </Summary> Public void redirecturl (string key) {string url = xmlhelper. getvalue (key );}}
 

Of course, it is not a good solution to jump the service address by providing a possible idea.

Through the above explanation, we know that the update of the view does not propose who will complete the operation. Generally, there is a 2-mode model. Let's take a look.

Next we will talk about S's solution to the view update mode in ASP. net mvc mode.

Let's take a look at the variants of MVC developed on the Web end, that is, the model2 mode. Let's first look at the changes in this mode compared to the previous MVC mode.

The main difference lies in the following aspects. In the MVC mode, the view has a certain relationship with the model. Changes to the model will notify the view and view updates through the observer mode, we actively invite users through the view

While in model2, views and models are independent, and views are updated through controllers, the Controller notifies the view and data changes based on model changes.

In this mode, user operations are not captured through views, but are completed by a Web component and a front-end controller. The front-end Controller is responsible for intercepting HTTP requests, then, based on the request URL and HTTP header information,

Determine which controller to use to process the request.

Basically, this process is the processing process of model2. This stream

Cheng is also the pattern used behind the APs. Net MVC framework. I believe that your understanding of the content will make it easier for us to understand it in the process of using the framework.

What are the advantages of model2 compared with MVC?

It is certain that model2 has better adaptability, better testability, and maintainability, and is more efficient than the original MVC mode. What should I do?

Original MVC mode process: our page request process is like this. each user's operation will generate an HTTP request, and then the server maps a processing page according to the request address, then open

Starts a lifecycle to complete user operation requests.

Model2 mode flow: we know from the above figure that user operations are also captured by the front-end controller through HTTP requests, and then the controller gives control to the specific controller for processing,

You need to hand it over to the specified page for processing. In this way, you also need to create a lifecycle for the page. At the same time, this method can make the view passive, instead of actively updating, we move our focus to the Controller,

Test is easier than view.

We need to note that the model in model2 is neither a business model nor a domain model. This model is an object that interacts with a view. We call it viewmodel. The MVC Framework will provide us with

Containers corresponding to viewmodel. The container is responsible for creating various viewmodel objects. The prevalence of MVC is also because it applies the principle of system architecture: the importance of separation power points, so it will become so popular.

But MVC is not perfect. Let's take a look at another type of MVPs that are insufficient to improve MVC.

4.3.2 MVP Mode

Let's take a look at the explanation of the MVP mode. The MVP mode replaces the controller in the MVC mode with the display device. The MVP mode cleverly separates the model from the View/controller. We call it the display device, we need to know that the MVP mode is derived from the MVC mode. In the MVP mode, we usually perform interaction in this way, and the presentation accesses the view through the interface. The purpose of doing so is, the display will not care about the view implementation

As long as the interface is implemented, the corresponding service can be completed through the display device. Of course, if we need to consider the call before the dashboard and model, if we also use interfaces, we will focus on the display.

In this way, it is easier to test, and views and models can be simulated. This will greatly improve the testability. Next let's take a look at the difference between the MVC and MVP modes. We can still see what the figure says

This is more intuitive.

MVP mode:

MVC mode:

Through the above figure, we should be clear about the improvement of the MVP mode over the MVC mode? I will not explain it here. In MVP mode, we pay more attention to the interaction between the display and view.

One of the main purposes of the mode is to form a low coupling form through interface call between the display and view. We pay more attention to the display, then the views implemented by different technologies access the same accesser to complete the general

Service. This method is similar to SAAS, where software is a service.

Let's take a look at the workflow of the MVP model:

In fact, the MVP mode is not easy to implement, because the MVP mode needs to define a View Interface and display device for each page. When the system page has a certain size, this will be very big work

Quantity. Therefore, we need to decide the architecture model based on the project's needs.

Let's take a look at a new model derived from the MVP model: presenter model, which is mainly applied in WPF and also called application model.

What is the difference between MVPs?

Let's take a look at it. In general, the difference is not big. PM is more suitable for the mode used to build the presentation layer in WPF and Silverlight. It is the same as the MVP mode and also has three roles, view, display, and model.

In MVP mode, we define interfaces for views, and then the dashboard calls interfaces to interact with views. However, we bind the View data through the view implementation interface. So

The specific implementation technology can be different.

In PM mode, the view does not expose any interfaces. In this mode, the data model bound to the view is introduced in the display device. In this way, the view is passive. When the status of the data model changes

Because. NET Framework has provided synchronization of underlying data binding, the view is automatically updated when the model status is changed. This two-way binding method is used to complete our previous

The functions completed by the MVP mode are different from those in the interaction structure. Let's take a look at the Interaction Relationship between the three roles in the PM mode:

Knowing the relationship between the three roles, What is the specific process? It is easier to understand.

The view and model are bound in two directions. Both parties automatically change the view and model according to the changes of one party.

New, in fact, views are passively updated based on changes in entities. The dashboard receives user actions, executes the corresponding business logic, updates the model, and changes the model, because the view is bound to the model

The figure also changes passively. We can regard the model here as a class like a data transmission object, but it only has the attribute of storing data without any carrier of behavior. PM mode in WPF this mode is called mvvm.

Let's summarize the application situations of different UIS in these modes:

We will summarize the application scenarios of different models here, hoping to help you design projects in normal times.

V, Conclusion

This article describes some common basic class presentation layer modes in the presentation layer of the system architecture, and briefly describes the underlying principles of these modes. Too many instance generations are not provided here

Code, because some of the following examples will use some of the models here, such as MVP and PM models. If yes, I will give an example to illustrate the application of these models separately.

VI, Series progress Previous

1. System Architect-from basic to enterprise application architecture series-useful for volume opening

2. System Architect-Basic to enterprise application architecture-system modeling [Part 1]

3. System Architect-Basic to enterprise application architecture-system modeling [Part 1] (Part 1)

4. System Architect-Basic to enterprise application architecture-system modeling [Part 1] (Part 2)

5. System Architect-Basic to enterprise application architecture-system modeling [Part II]

6. System Architect-Basic to enterprise application architecture-system design specifications and principles [Part 1]

7. System Architect-Basic to enterprise application architecture-system design specifications and principles [Part II]

8. System Architect-Basic to enterprise application architecture-design mode [Part 1]

9. System Architect-Basic to enterprise application architecture-design mode [Part 1]

10. System Architect-Basic to enterprise application architecture-design mode [Part II]

Part II

11. System Architect-Basic to enterprise application architecture-enterprise application architecture

12. System Architect-Basic to enterprise application architecture-hierarchy [Part 1]

13. System Architect-Basic to enterprise application architecture-hierarchy [Part 1]

14. System Architect-Basic to enterprise application architecture-hierarchy [Part II]

15. System Architect-Basic to enterprise application architecture-performance Layer

16. System Architect-Basic to enterprise application architecture-service layer

17. System Architect-Basic to enterprise application architecture-business logic layer

18. System Architect-Basic to enterprise application architecture-data access layer

19. System Architect-Basic to enterprise application architecture-Component Service

20. System Architect-Basic to enterprise application architecture-Security Mechanism

Later

21. Full Analysis of stand-alone applications, clients/servers, multiple services, and Enterprise Data Bus

22. System Architect-Basic to enterprise application architecture-standalone application (instance and demo)

23. System Architect-Basic to enterprise application architecture-Client/Server (instance and demo)

24. System Architect-Basic to enterprise application architecture-Multi-Service (instance and demo)

25. System Architect-Basic to enterprise application architecture-Enterprise Data Bus (instance and demo)

26. System Architect-Basic to enterprise application architecture-performance optimization (Architecture bottleneck)

27. System Architect-Basic to enterprise application architecture-complete architecture solution example [Part 1]

28. System Architect-Basic to enterprise application architecture-complete architecture solution example [Part 1]

29. System Architect-Basic to enterprise application architecture-complete architecture solution example [Part 2]

30. System Architect-Basic to enterprise application architecture-Summary and follow-up

VII, Next announcement

In the next article, we will begin to explain the hierarchy in the system architecture-from top to bottom-to discuss and analyze the design scheme. These are my work experiences. Due to my limited ability, weaknesses,

Please note more. I hope you will continue to pay attention to it!