. Net enterprise-level application architecture design-Presentation Layer Design

Summary

No program can run without a user interface. Even if the middle-Layer Code is perfect, users cannot use it. Many architects do not pay much attention to the presentation layer. They only process the presentation layer as a detail after the business layer and data access layer are completed. However, the user interface, business logic, and data access code are equally important in any system. Your attitude, preferences, and professional skills determine the "Priority" You set for each layer, which also leads to the order of attention to each layer.

In actual development, the presentation layer is often the last part of the system development, and is very dependent on functions provided by development tools such as. A large part of the work at the presentation layer can be done by powerful advanced tools. However, the emergence of these powerful tools may make architects and developers less important to the good design of the presentation layer. The implementation of the presentation layer can be very simple or complex. Therefore, you can use the Rapid Application Development (RAD) tool, wizard, and gadgets to directly bind to the database at the beginning, but you also need to have a clear understanding of your current practices. If the presentation layer gradually becomes more complex, that is, it becomes a graphical presentation layer with the logic of many applications, then the specifications and modes should be used for sorting, just like the practice at the business layer and data access layer.

The presentation layer consists of two main components: the user interface and the presentation layer logic. The user interface provides the user with a utility interface. All the activities of the program are exposed to the user through graphical elements or text elements in the user interface. These elements are used to provide information, suggest next operations, and input devices, such as the keyboard and mouse, to capture user activity. Any operations performed on the user interface will become another component of the presentation layer, that is, the input of the presentation layer logic. The presentation layer logic refers to all the logic used to process the data to be displayed, plus the logic used to convert user input to the command of the background system. In other words, the presentation layer logic is responsible for the interaction of data streams between the middle layer and the UI.

Performance layer responsibilities

If you ask a software engineer to list the accusations at the performance layer, you will surely hear the following descriptions: verification, formatting, adding styles, and availability. However, availability is more like a property rather than a responsibility, and features such as verification, adding styles, and formatting should belong to the UI component rather than the presentation layer.

As an architect at the design performance layer, you should be more advanced, at least at the beginning. The role of the performance layer should be considered from a higher perspective, that is, it does not rely on the physical UI, high testability and data model.

Independent from graphical elements: graphical elements form the user interface of the application. You can view and interact with these components to transmit commands and information to the background system. However, the presentation layer must ensure that any modifications to the graphical user interface do not affect the data stream and presentation layer logic. As long as the changes are purely graphical changes, the presentation layer must be transparent. The real example is the user interface system that can switch the theme style and layout, such as Weibo, blog, and CMS.

Independent from the UI Technology: The presentation layer must not rely on the UI technology and platform. This requirement is more difficult to implement and sometimes cannot be completely independent. Maybe we should say that we do not rely on the UI technology as much as possible. A common requirement is that the system must support many performance layers, such as web, mobile devices, and windows. When you need to enable a single functional user interface to support a variety of UI technologies and platforms, a well-designed performance layer allows developers to reuse existing code as much as possible. It is difficult to expect 100% reuse, so it is more realistic to "maximize code reuse" as the goal is.

Support for testing: abstraction is a key tool for improving testability at the presentation layer. abstraction can be achieved by separating the focus, separating the view and presentation layer logic.

Independent from the data model: No matter what model is selected in the middle layer, the performance Layer should not be affected, or the performance layer should be as unaffected as possible. Theoretically, each method called from the presentation layer to the application logic requires a pair of input and output data migration objects. With this in mind, we will restrict the use of data migration objects and only use them where the system is most likely to change. In the specific circumstances of the performance layer, it is acceptable to have some dependencies between the layer and the data model. However, this must be done because it can bring obvious performance or maintenance advantages.

Responsibilities of the user interface

Generally, architects are not directly involved in the design details of the graphic interface. The architect's primary responsibility is to ensure that the product meets all the important quality features, especially availability and accessibility. The most tricky part of the presentation layer logic is to design an abstraction for each view in the presentation layer, which defines the input and output data exposed in the view. The final goal of the presentation layer logic is to ensure that the data in the view can be correctly inbound/outbound. After all project stakeholders confirm the public interface of each view, the two teams can develop the interface at the same time.

Each view that forms a user interface has its own responsibilities. Most of these responsibilities also ensure that the presentation layer is easy to use.

Real-time data display: One of the responsibilities of the user interface is to display data to the user, including common information, prompts, and Application Operation responses. A well-designed user interface should provide users with properly formatted data and be displayed visually. The specific implementation location for formatting data so that it can be displayed varies depending on the mode selected in the presentation layer design. Most of the time, this operation is in the presentation layer logic, but some of the formatting and display logic is placed in powerful controls on the user interface.

Comfortable data input: enter user data into the system on the user interface. A good presentation layer provides input format rules and provides appropriate input controls, this allows users to easily input data. From this perspective, rich controls and drag and drop have great advantages. In addition, tabs can also group complex functions so that users only focus on the current part. Remember that all user input is evil, so the user interface must provide preliminary verification functions. Although UI-level verification is not complete enough, it is best to start from here.

Overall appearance: the appearance and feeling of an application are the main characteristics of the user's experience and overall appearance when using the application. Generally, the applications to be used by the public must have exquisite user interfaces, because one purpose of the software is to capture the user's attention and leave a good impression on the user. For internal programs within the company, the interface tends to implement functions, rather than the shock of visual effects.

Common mistakes on the presentation layer

Before discussing the design patterns, I would like to introduce several common mistakes related to the presentation layer.

The presentation layer development relies too much on RAD tools: VS brings developers a complete set of practical tools, which seem to imply that developers should not waste time on design and separation of focus, this is, of course, a natural product of the rad concept. Double-click the button to write code conveniently and quickly. However, Rad is not an ideal performance-Layer Development Choice for large enterprise-level systems. We recommend that you use vs as a quick uidesigner instead of a quick application development tool. Vs and all of its rad features are constantly inducing us to use them in various situations. However, in some cases, we should turn a blind eye to it to avoid clicking and writing more code manually. The uncontrolled misuse of the rad development model will allow you to create a lot of autonomous views. The so-called autonomous view refers to a class to write the user interface status and all the actions in it. Autonomous views are no longer popular, but the main reason is that they are hard to be tested.

Boundary of the presentation layer: the responsibility of the presentation layer should be determined only by the scalability and performance requirements. At the same time, the presentation layer should only contain the logic that belongs to the presentation layer, and perhaps add some mixed or repeated values, which are carefully weighed and fully aware of the existing business logic. Even worse, the various convenience facilities related to the user interface keep tempting developers to include some code that does not belong to the performance Layer. This problem can be seen in most projects. The UI must be isolated from the code, and the Code must also be implemented hierarchically, highly complying with the principle of separation of focus.

What users get is what you want: When you use declarative rather than imperative programming, some responsibilities are assigned to another layer of code, which you cannot control. In development, entrusting some functions to a third party will increase the development speed. However, you also need to ensure that you can get what you want accurately.

Evolution of the Presentation Layer

Separating presentation logic from business logic is only the first step in sound design. The internal organization of the presentation layer logic depends on the selected UI mode. In the final analysis, there are three main types of presentation layer modes: Model-View-controller (MVC), Model-View-Display Device (MVP), and PM. Many models are evolved from these three types. For example, model2 evolved from MVC and mvvm evolved from PM.

MVC originated from a fully object-oriented environment. It simplifies the testing of the user interface and tries to remove the code from the view as much as possible. It also helps the code to be more structured and logically partitioned. MVC should be as passive as possible, which means that the view should be only responsible for processing the content presented to the user. In MVC implementation, the Controller updates the model by executing the triggered operation. Then the status of the model Notification View changes. Views and models are bound together in the Observer mode. In observer mode, the active party notifies the observer when the change occurs. Then, I tried to read the current status from the model and update it accordingly. MVPs are inherently complex and only suitable for enterprise-level applications or projects with sufficient complexity and strict patterns and policy assurance.

The MVC mode has two major shortcomings. One is that the model needs to communicate with the view to inform the model of changes in state. The other is that the view has an implicit understanding of the model. MVPs are a derivative model of MVC and strive to better separate views, models, and controllers from each other. It can be said that MVP is an improvement of MVC for three reasons. The view does not understand the model. The dashboard will ignore the specific UI technology and view used in the view and can be simulated for testing. The core of MVP is to strictly determine the interaction between views and controllers. In MVP, the Controller name is changed to the display device, so its core value is to define the interaction process between the view and display device. MVP visual view should be as simple and passive as possible, but this is only available in theory. In fact, a completely passive view is very difficult to compile and maintain, and may even cause a lot of trouble to the display. The law of conservation of software complexity indicates that the complexity in software systems is conservative and can be transferred from one layer to another. That is to say, the total amount of logic at the presentation layer remains fixed, and all you can do is decide where the architecture places it. According to the law of conservation of software complexity, the reduced complexity from the view will be moved to another layer, which is the display device. Passive view will inevitably lead to more complex display devices. Selecting a passive view is actually a highly testable choice, and brings a high complexity in the display class. The name of the dashboard can better describe the components responsible for processing user operations. The dashboard will "display" user requests to the background system, and then "display" the response to the user. The dashboard is located between the view and model. It obtains user input from the view and passes commands to the following model. Then the dashboard obtains the operation result and updates the view through the structure provided by the view.

There is no big difference between the PM mode and the MVP mode. It is considered another variant of MVP, which is especially suitable for complicated and rich user interfaces. On the Windows platform, PM is very suitable for applications developed using WPF and sliverlight, which is also recommended by Microsoft. You can use the MVP mode if you want to have more powerful features than the. NET built-in UI in Windows Forms, WPF, or sliverlight. If you often use bidirectional binding in WPF/and sliverlight, you can consider the PM mode. in WPF, this mode is also called mvvm.

Summary

In fact, the presentation layer is no less important than the business layer and data access layer. The presentation layer without intermediate core behaviors is useless even if it is dazzling. However, without the combination of the presentation layer, even a powerful middle layer cannot meet user needs.

Related blogs:

• . Net enterprise-level application architecture design: Contemporary architects and Architectures
• . NET Enterprise Application Architecture Design-UML
  
• Design principles and models for. net enterprise-level application architecture design
• . NET Enterprise Application Architecture Design-Business Layer Design
• . Net enterprise-level application architecture design-service layer design
• . Net enterprise-level application architecture design-data access layer
  
• . Net enterprise-level application architecture design-Presentation Layer Design