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

ArticleDirectory

• I. Review in the previous chapter
• Ii. Summary
• Iii. Outline of this Chapter
• Iv. Multiple Ways to separate concerns
• V. Related Design Methods
• Vi. Summary in this Chapter
• VII. Series progress
• 8. next announcement
• IX. Demo download

I. Review in the previous chapter

In the previous chapter, we mainly discuss the specific principles and norms in the system design specifications and principles. How to achieve a design that meets the specifications is also described through the separation of power points to achieve, and in the software development process

The method of implementing the object is simply divided into process-oriented and object-oriented development methods. At present, there are more object-oriented development and design methods. For details, see:

Describes the software design principles: low coupling, high cohesion, and briefly describes how to implement these two principles by separating the focus. We call the function a focus.

Ii. Summary

This article will explain how to use the separation function points through examples, and explain the issues that should be paid attention to when implementing the corresponding function points. For example, the content of some important parts. The separation function is soft

An important foundation of component functions. With the increasing complexity of software, the traditional technology of separation of focus is to separate focus only in one way, such as by function or by structure, which leads to more and more focus.

Not effectively and fully separated. Therefore, effective and adequate separation of focus is an important standard for us to better implement software functions, so if we want to achieve this purpose, we must conduct software in multiple ways at the same time.

Decomposition, because the more detailed the decomposition, the clearer the system design, it is easier to meet the design principles. By separating concerns, software complexity can be minimized and the comprehensibility can be improved.

This article will illustrate how to separate concerns in multiple ways at the same time. Because the content in this article is my experience and summary of the work process, the shortcomings are inevitable, please put forward your own

Comments and suggestions. Mistakes are inevitable. Please criticize them.

Iii. Outline of this Chapter

1. Review in the previous chapter.

2. Summary.

3. Outline of this chapter.

4. Multiple Ways to separate concerns.

5. Related design methods.

6. Summary in this chapter.

7. Series progress.

8. next announcement.

Iv. Multiple Ways to separate concerns

My understanding is that there are several ways to separate the focus (functional points) and the principles of each division. Next we will explain how to divide a system in different ways, abstract function points to reduce Software System

Complexity, and improve the system's comprehensibility.

1. Divide by Model

The models here are divided into conceptual models and physical models: Of course, the conceptual model here is an abstract model. For example, we usually say that the separation of functions is based on B2C product management, product Management

The minimum function is to select the product category, product unit, product extension attributes, product brand, and other related attributes. So let's talk about the concept model as an abstract model.

The descriptive method.

This is a must for adding a product.

Separation of energy points.

So how can we implement the physical model of product management on the physical model? Let's take a look.

A simple explanation is the specific business design model for each function point. The physical mode is the implementation of the conceptual model.

2. Hierarchical Division

The hierarchy can be simply divided into the layered separation and the cross-cutting separation. For example, we all know the cross-cutting and vertical cutting, that is, the perspective of the problem, the following is an example of how to use the two

Method To separate power points.

Of course, we still use the B2C system as an example to illustrate this situation. Let's take a look at the method of stratified separation.

Our B2C can be layered simply as follows. The business logic layer and interface are called through the service layer, which can avoid coupling between the UI Layer and the business layer.

The logic layer interacts with the database through the data access layer. Of course, some of my designs here are still unreasonable. Please give us more valuable comments so that this design can be improved.

Now let's take a look at the cross-cutting splitting method. We know that our system may record the detailed operation information of the administrator or any operator.

It will be processed by means of logs. The cross-cutting method is used by the system in any function from start to end. This is a process of horizontal separation of concerns. Then, when designing system operation logs, we will record the corresponding

Or system error logs.

Operation logs and error logs run through each layered structure. The method for separating concerns horizontally is AOP (Aspect-Oriented Programming ). Of course, we will introduce the Implementation Details of AOP later.

V. Related Design Methods

This section describes in detail the implementation of the two programming methods of separation of concerns between hierarchy and cross-cutting, and analyzes the implementation of the design method through different aspects of attention through programming methods. The two programming methods described here are oriented

The object programming method achieves separation of concerns in Layered mode and cross-section programming method to achieve cross-section separation of concerns.

1. Object-oriented Design

First of all, object-oriented programming is a kind of thinking. I think most of my colleagues in the garden are familiar with it. I will not discuss object-oriented design in detail here, here we will only talk about a few

Principles and considerations.

We know that object-oriented programming is to regard everything in the world as an object, and complex functions can be seen as the relationship between objects. After separating the focus

Note points further refine the relationship between multiple objects and objects.

Let's take a look at several basic principles in Object-Oriented Design and give examples respectively:

A. First, the relationship between objects and objects must be analyzed from the separation concerns. For example, we use shop management in B2C systems.

The figure briefly describes the objects in store management.

The figure briefly describes the relationship between objects. The store information depends on the store level and store type information, and the shop authentication information.

Dependent store information.

B. After the object is separated, let's take a look at several related principles of the class corresponding to the object:

(1) (SRP) The single responsibility principle is simply that a class provides only one function and only one factor that causes it to change. If we find that a class has multiple factors that cause its changes, we must do it.

To separate classes. The following is an example. Here we use the entity interface layer in the Orm.

Public interface ientity {// <summary> // save // </Summary> // <returns> returns the number of affected rows </returns> int save (); /// <summary> /// Delete /// </Summary> /// <returns> returns the number of affected rows </returns> int Delete (); /// <summary> /// write log information /// </Summary> /// <Param name = "message"> write information </param> /// <returns> returns the number of affected rows </returns> int writelog (string message );}
 

Obviously, the write log here is obviously not tied to the previous Object Persistence operations. This may cause two reasons that cause class changes to be separated, you must extract it and define an interface separately. The modified result is as follows:

Public interface ientity {// <summary> // save // </Summary> // <returns> returns the number of affected rows </returns> int save (); /// <summary >/// Delete /// </Summary> /// <returns> returns the number of affected rows </returns> int Delete ();} public interface logger {// <summary> // write log information // </Summary> // <Param name = "message"> write information </param> /// <returns> returns the number of affected rows </returns> int writelog (string message );}
 

(2) (OCP) closed development principle: Simply put, the existing class cannot be modified, but new functions need to be extended on the features of the class, in this case, the principle of open and closed is used to meet such requirements. This principle makes me

They can not only embrace changes, but also do not modify existingCode. The implementation of this principle is simply to abstract the behavior of a series of changed classes into interfaces, and then let these classes implement our definition.

The caller operates through the interface. For example, we use an MP3 player.

Public interface imp3 {// <summary> /// play // </Summary> /// <returns> whether the return operation is successful </returns> bool play (); /// <summary >/// stop /// </Summary> /// <returns> whether the return operation is successful </returns> bool stop ();}
 

Define two different implementations

/// <Summary> // audio player /// </Summary> public class TD: imp3 {# region imp3 member public bool play () {return true ;} public bool stop () {return true ;}# endregion} // <summary> // HP player /// </Summary> public class HP: imp3 {# region imp3 member public bool play () {return true;} public bool stop () {return true ;}# endregion}
 

Simulate interface calling through a test class and implement it through dependency injection.

Public class test {imp3 MP3 = NULL; public test (imp3 MP) {MP3 = mp;} public bool play () {return mp3.play ();} public bool stop () {return mp3.stop ();}}
 

I will not write the specific test code. I think everyone knows it.

(3) (LSP) replacement principle: Simply put, it is the place where the base class appears. extension classes can be replaced, so the premise is that we cannot modify the behavior of the base class. That is to say, the base class and the extension class can interact with each other.

. Objects may be considered easy to implement, but we must note that the behavior we inherit from the parent class may change due to the rewriting of the Child class, at this time, it may not be able to meet the requirement of not changing.

The behavior of the base class. The polymorphism we are most familiar with does not satisfy this principle. Note that the base class is not the same as the derived class for the caller.

Public class test {private int tempvalue = 0; Public void TESTA () {tempvalue = 2;} Public Virtual void testb () {tempvalue = 9 ;}} public class test1: test {public override void testb () {// if this method is called, the value of tempvalue can be the same as the value obtained in the base class. If no display shows how many methods are called, then this value will be lost // it does not meet the replacement principle. Base. testb ();}}
 

From the simple code above, we can see that attention should be paid to the lee's replacement principle: When you need to pay special attention to classes or methods with virtual keywords and saled keywords, because these keywords will inherit the class

Action has a certain impact. Of course, the above example only describes the rewrite situation, and there is a new situation, that is, hiding the methods in the parent class, also does not meet the principle of Lishi replacement. In this example

Tempvalue is a private variable, which can be accessed in the base class but cannot be accessed in the derived class, when replacing the base class, pay attention to the access domain of the inherited member functions. The recommended method is

Try to use the protection type for the member variables of the class accessed by the virtual method to prevent loss. Of course, there are virtual methods in the base class to access the private variables defined in the base class. If you want to avoid losing the base class in the inheritance class

Class, you can use the "base. (function name) to display the call to the base class method, can maintain the behavior of the base class.

(4) (DIP) Dependency inversion principle: simply put, it depends on abstraction rather than implementation. This aims to reduce coupling. Simply put, the dependency between two classes is solved through interfaces.

Coupling, let a class depend on an interface, and then let another class implement this interface, through the construction of injection or attribute injection to implement dependency. In short, abstraction does not depend on details, and details depend on abstraction. Lower

Here is an example:

 
/// <Summary> // Automotive Braking System /// </Summary> Public interface iControl {int upspeed (); bool brake ();} /// <summary> /// other services /// </Summary> Public interface iServer {bool Radio (); bool GPS ();}
 

Specific Use

/// <Summary> // automobile // </Summary> public class car {private iControl control = NULL; private iServer Server = NULL; Public Car (iControl, iServer Ser) {control = con; server = SER;} public void start () {control. upspeed ();} public void play () {server. radio ();} public void map () {server. GPS ();}}
 

The above simple example shows that no specific implementation is provided. You only need to implement the above two interfaces. I hope you can understand it here. Please note the errors.

(5) (ISP) interface isolation principle: In simple terms, the customer only cares about the services he can obtain if he does not care about the details, as we all know, the object-oriented principle is proposed through interfaces.

For service. Therefore, we provide customers with a series of interfaces, so that they have good low coupling. Here is a simple example: simple persistence operations in ORM

Public interface Iorm {// <summary> /// save /// </Summary> /// <returns> returns the number of affected rows </returns> int save (); /// <summary> /// Delete /// </Summary> /// <returns> returns the number of affected rows </returns> int delet (); /// <summary> /// obtain all lists /// </Summary> /// <returns> Returns a datatable </returns> datatable getlist ();}
 

Here we use an entity to inherit and implement it.

 
Public class ORM: Iorm {# region Iorm member public int save () {return 1;} public int delet () {return 1;} public system. data. datatable getlist () {return new system. data. datatable () ;}# endregion}
 

Implementation of the Business Layer

 
Public class entity {private Iorm ORM = NULL; public entity (Iorm ORM1) {ORM = ORM1;} public int save () {return Orm. save ();} public int Delete () {return Orm. delet ();}}
 

Here I will not post the implementation of the test code. I will post the code for download later. If you are interested, you can download it. Of course, I am only here to introduce some of the shortcomings.

. There are still many principles in object-oriented design, which will not be repeated here. This is just the tip of the iceberg. I hope you can give more valuable comments.

2. Aspect-Oriented Programming

Aspect-Oriented Programming is actually Aspect-oriented programming. In fact, this concept was put forward a long time ago, but it is not widely used. It is quite confusing, I usually use

Relatively small. However, we are very useful in the system architecture, especially in the process of separation of concerns. The main purpose of AOP is to combine the cross-cutting concerns with the core layered form or

Feature component separation. Next we will look at how to implement programming in AOP.

The aspect of Aspect-oriented programming is not implemented by a compiler directly, but is to merge the aspect into the conventional one in a special way.Source codeAnd then compiled by the compiler. We know that

It is a cross-cutting concern. In the implementation process, we usually need to define the connection point and the notifications based on this connection point. Let's take a look at the source code processing model of AOP:

Generally, AOP has a framework to provide the injection function, and the code injection function here is different from our object-oriented dependency injection function. Note here

The inbound code is embedded into regular code snippets.

Next we will introduce the connection points and notifications in AOP.

Connection point: it is used to identify the position of an implant in a certain type. The connection point can be a call to a method, an attribute accessor, a method subject, or others. A connection point is generally used to identify the injection of a certain

The position of the Code in the aspect type.

Notification: identifies the specific code injected into the type. In short, it is the code to be injected.

Currently, the basic function of AOP is provided in. net. Piab is an implementation method of AOP in. net. Let's talk about it briefly. Of course, many big cows in the garden have discussed this.

Piab introduction and usage. You can refer to these articles.

Generally, we have two injection methods on the. NET platform. The following is an illustration:

The specific implementation scheme is not comprehensive here. However, there are usually many implementation schemes in the runtime, and third-party implantation tools are required for implementation in the compilation phase,

Complete the code implantation before compilation, and ensure that the embedded code can be compiled.

For more information about piab, see the piab series enterlib piab deep analysis by artech.

Vi. Summary in this Chapter

This chapter describes in detail how to implement the specifications and principles of software design. The focus is separated by object-oriented and object-oriented programming, and the principles followed in the implementation process. And analyzed the separation of concerns

The separation methods and perspectives in this article are separated from each other in multiple ways and from multiple perspectives. Of course, this article is just a reference and a reference to the shortcomings. Please give more valuable comments. You will continue to improve your performance in subsequent articles. Thank you!

VII. Preparations

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

8. next announcement

In the next article, we will begin to explain the most important and basic skills in software design-the design model, in the next three articles, we will explain how to use the design pattern and design in the project.

The following describes the possible scenarios of each design pattern. I hope you will continue to pay attention to it!

IX. Demo download

Download: Click to download