Application Framework Design (reproduced in this article)

Introduction to Application Framework Design

Make an applicationProgramThe idea of the Framework bigtall came into existence a few years ago, because many aspects of work were very difficult, and almost every stage had the following problems:

• The Design of different project teams in the company is completely different, and the design is not detailed, resulting in more and more forms of project planning.
• LayersCodeMessy, from the back-end Java or C # To the front-end HTML.
• The database structure does not match the document. If it is not an inexplicable combination of multiple or fewer fields, or some inexplicable names

If you go deep into the design aspect, you will find that although you have done a lot of projects, there are almost no successful cases for reference. All the designs, even the same type of projects, will almost begin to begin; coding is even more troublesome. I was most impressed by the fact that I have compiled countless string processing functions, including C/C ++ and C, there are Java versions, Delphi, and VB that have long been forgotten. Of course, more importantly, the popular JS (which is better ). Once the project scale is large, we may even get lost in the Code flow, without knowing where the call comes from, or where the logic will jump.

So many problems are common problems of the majority of software enterprises in the CMM Level 1, of course, they will also appear in those software enterprises in the actual or CMMS level. Joining management means (such as implementing CMM specifications) can solve most of the problems, and, accurately, can solve almost all management problems and ease most of the technical problems, but it cannot solve all the problems.

In the past, bigtall used to say that "technology is not important, and market and management are the most important." In the end, the company entered a low point, it's hard to gather more talent. The lessons learned by others are their own experiences. bigtall was later deeply reflected and held that there is a problem of "degree, let's first look at the two extreme "only market and management but no technology" and "only technology without market and management". One is "unable to hold" and the other is "cannot push ". In fact, they complement each other. technology can push up the threshold of the market, and market and management can make the technology develop smoothly. Therefore, a company does not have the "best" technology, but only the "most suitable" technology. A company's technical goal should also be to "continuously reduce the company's costs ".

The most obvious problem is the reuse of the project system design. No matter how many levels of CMM you are, without a unified software architecture, reuse will be compromised or even impossible at all. Just like the southerners who use Mandarin to communicate with each other, they must use the same text (by the way, despise and pity North Korea, South Korea, and Vietnam) to communicate with each other, they need the same structure. Therefore, the "Program Framework" is the "Mandarin" between company projects and the "lubricant" within the project ".

Here we need to clarify the differences between "Framework" and "architecture". Simply put, a program framework is a set of code that can be applied in practice, the software architecture can be seen as an abstract design. In addition, the two aspects of attention are different. The program framework is keen to solve problems in the actual operation process, and even provides toolkit or auxiliary modules (such as permission systems and log systems ), the software architecture focuses on the relationship between various parts (modules and components. The two are actually about different levels of the same thing.

Let's take a look at it. If there is a program frameworkArticleHow many problems are solved at the beginning:

1. If there is a program framework, because the WBS of the project is almost the same, the project plan of the previous project can be used directly. After several projects, the templates for this project plan will become increasingly detailed and more practical.
2. In addition to requirements, the overview design and detailed design are highly reusable during the design process.
3. Because of the consistent structure, code obfuscation reduces to an acceptable level and can reuse most of the code of the previous project. The logic is clear, making the code relatively small and not easy to lose in the code. Because the code logic is simple and orderly, it is easy to test.
4. Reduce management costs. In addition to project plans, test plans and QA plans can be reused. If CMM specifications are used, the speed and quality of project reviews will be improved.

It is not easy to build an application framework. First, it has developed rapidly and has a relatively high level. If there is no unique solution, the framework may be out of date. Second, the application framework involves many aspects. It is not easy to consider clearly. Third, it takes a lot of time to develop an application framework, that is, the company needs to spend (your salary × development time + others) so much money.

For small companies, unless they have a clear understanding, developing their own application frameworks may be self-seeking. Bigtall is recommended for small companies.. NET development, the petshop4 framework is used directly. If Java is developed, appfuse is used directly for development. If you want a new language, use Ruby on Rails for development. I am not very familiar with PHP.

To develop an application framework, you must meet at least the following conditions:

• Layering (nonsense)
• Easy to test
• It is easy to scale and seamlessly integrated with other existing systems. Generally, it must have AOP, IOC, and di capabilities.
• Easy to deploy
• Permission and user management
• Supported by organizational architecture, workflows, and rule Engines
• Page flow and status management capabilities
• MOF or MDA capabilities
• SOA capability
• Abstract capabilities of interface technologies (such as webform, HTML, Ajax, XML, and rich web)

The Application Framework Design Series of bigtall documents are prepared to record and present the entire process of the bigtall development framework step by step. The following is a list of articles:

1. Data transmission between multiple layers of applications: data transmission between layers (top), layer data transmission between layers (bottom)
   Multi-layer architecture has become a standard, but what changes and patterns does the data form when it crosses all layers?
2. Analysis and abstraction at the Interface Layer
   The interface layer carries all the visible parts of the application. How many facts do we need to pay attention to but ignore?
3. MOF/MDA support and Program Design Specifications
   If people are not reliable at all, do not do it as much as possible. But at this step, what else do we need to tell the machine?
4. Tool! My tools!
   Bigtall-designed gadgets
5. To be continued

Application Framework Design II: hierarchical and inter-layer data transfer (I)

Do you still remember the conflict between fat clients and thin clients that started around 97 years ago? Then there is a battle between CS and BS, and then a battle between two and multiple layers ..., ten years later, let's look back at these arguments. Everything seems to be so justified: How can programs not be layered? However, it took us ten years to reach a multi-layer consensus on a program architecture (low efficiency )!

To be layered, of course, it is basically three layers. In fact, the basis of multiple layers is also three layers: interface layer, business logic layer, and storage layer. Multiple Layers only split each layer more or less on the basis of the three layers. In general, there is no major change. The three layers are the basic concepts discussed in this series of articles.

This article focuses not on how to layer and how to define layers, but on how to transfer data between layers. Currently, the program seldom analyzes the data transmission problem between the layer and the layer. Generally, an object passes through the interface from the generation of the interface, save it directly to the database (the most notable mark is xxxid ). This method is very harmful to the program.

First, let's start with a simple example: Adding User features to an application. The interface is simple as follows:

 

Add User

Login Name
Password
Add User

 

It is usually very easy to design a data structure for this interface. Class logininfo {public string name; Public String password;} is fine, then, when the form is submitted, a new logininfo structure is added and logininfo is saved to the database. The most common method is to add an int logininfoid field. We name the data structure similar to logininfo that can be directly stored in the databasePersistence object (PO for short). Well, it seems that there is no problem to use a data structure from the beginning to the end!

The problem may occur. bigtall is used to change the requirement. We usually need to enter the user password twice, so the interface is modified as follows:

Add User

Login Name
Password
Repeated input
Add User

In this way, the data structure submitted by form to the server should be like this: Class logininfo2 {public string name; Public String password; Public String password2 ;}, then, the first thing the server does is to compare whether the password and password2 are equal, and then a new logininfo structure will fill in the name and password, and then save them to the database. We also modify the logininfo structure to the class logininfo {public int logininfoid; Public string name; Public String password ;}.

As you can see, as the demand changes, the original "po Express" has evolved into two structures. We call the data structure that is similar to the interface layer of logininfo2 and that of other layers to view object, VO for short. Is that enough? Of course not. Let's modify the requirement and add the permission function to the system. Therefore, the added user should actually be modified as follows:

Add User

Login Name
Password
Repeated input
Administrator Department Manager Ordinary employee
Add User

We need to continue to make some improvements (or "refactoring"). First, we need to modify vo and standardize the name:

Class logininfovo {public string name; Public String password; Public String password2; Public String [] roles ;},

Split the previous logininfo into three classes:

Class logininfobo {public string name; Public String password; Public roleinfo [] roles ;}

Class logininfopo {public int logininfoid; Public string name; Public String password ;}

Class roleinfopo {public int logininfoid; Public String role ;}.

So far, we have successfully introduced three concepts: view object (VO), Business Object (BO), and persistence object (PO ). They are the data structures used in the display layer, business logic layer, and storage layer of the three layers respectively. They are also collectively referred to as the data transmission object data transfer object (DTO ). We can also regard Vo, Bo, and Po as different DTO representations at different stages. When a DTO traverses the entire system from the display layer, its form and structure begin to change, from VO to Bo, and finally to Po, however, this process is not necessarily reversible. If this process is reversed from Po-> Bo-> Vo, it is likely to correspond to different objects. For example, when an input error occurs, an error message may be added to the feedback page. In actual use, we often ignore this subtle difference. In fact, this error message is only meaningful to the display layer.

The DTO conversion rules can be summarized into the following types. The actual changes can be combinations of various types:

• Attribute content reduction

The increase or decrease of attribute content often changes between different DTO forms. For example, when adding the VO of the user logininfo object to Bo in the above example, You need to discard the "repeated Password Input" attribute. Some VO objects do not even need to be converted to Bo. When Bo is converted to Po, attribute content will also be reduced, such as tree-level objects such as "departments", because of operational efficiency, you may need a "lower-level department list" in the Bo. The Po only needs a "higher-level department ID" when it is actually stored in the database.

• Object content filling or adding

The property content may also increase. However, when the system processes DTO conversions, adding the property may mean that additional queries and filling are required, for example, when we use the "user name" and "password" to log on, the system needs to query the database and store the "user ID" to ensure the uniqueness of the user. For example, if the submitted data has a verification error, we may need to refresh the page again and add the new attribute "errormessage" to display it on the interface to remind users of the error.

• Object splitting and combination

Let's look at the last "Add User" example above. When a logininfo Bo is converted to a po, it is split into two objects, one storing basic user information, stores the corresponding role information. When an object is split, it is often necessary to fill in or supplement the content of the new object. When the object is merged, the content is often reduced.

• Changes in object or attribute types

Changes in object property types are common in Vo-bo conversion. For example, you can convert your input birthday to a real datetime type.

• Attribute name changes

Attribute names may change during the conversion process. Generally, this case should not occur as much as possible, but it is more likely to happen during project reconstruction.

In addition to the conversion rules between different DTO forms, there are also different tasks to be done within different forms:

• Verification

"Do not trust any user input" is a principle that will always be observed when the design program interacts with the user. That is, all external inputs must be verified for correctness. The validator is divided into two layers. One is the validation of the attribute level. For example, the "Age" can only be between 0 and 150. The other is object-level verification, or cross-Attribute-level verification. For example, "a year can be entered as a leap year, and may take 29 days on January 29, February.

Verification is not a simple problem. Almost all business logic verification requires a complete call throughout all layers. High cost. This is also why we perform a lot of pre-verification on the display layer. Once we enter the business logic layer, the validation is often replaced by "post-verification, people will use the method of throwing an exception to replace "pre-check ".

Suddenly I think there is a gossip to talk about. This analysis process was actually completed a year ago. At that time, the surging SOA was everywhere. After the DTO form analysis was completed, I looked back at SOA and found that it was not a performance layer, it belongs to the business logic layer. In other words, The DTO used must be Bo rather than vo. The so-called SOA is just a distributed business logic layer.

Because the following sections require a lot of time to search, bigtall is afraid that the article will be delayed for a long time, And bigtall will be afraid that you will wait too long for the official readers. In the next article, we will focus on the comparison of several architectures on the net platform and Java platform in the DTO form. We will also discuss a practical question about whether the Object ID is required.