Best practices
Before we talk about basic patterns, let's start with a word: best practices.
Any program must be written in accordance with a specific specification. This specification has the convention commonly known for example: The package name is all lowercase, the class name each word first letter capitalization and so on and so on; there are some things we need to strictly follow: for example, when we write our own servlet, we have to inherit the Javax.servlet.http.HttpServlet interface.
Above the standard is the concrete implementation of the different standards. For example, with the servlet standard, Tomcat has a way of implementing it, and WebSphere has a different way of implementing it.
At the programmer level, different programmers have different implementations in the face of complex business processes. This is the difference between the program, we do not otherwise the difference is a little time to improve efficiency, but this difference in more time to bring is the maintenance of the difficulty of the increase. Although the business is different, the implementation of the underlying code is certainly different, but for maintainability and readability, we want the system to look consistent from the architecture hierarchy (macro level) above the code. This goal is what we call best practice.
All in all: Best practice is a set of specific methods that countless programmers have explored, tried, and summed up to deal with specific problems. If we take each programmer's freedom as a path to success, the best practices that predecessors have summed up are the shortest shortcuts.
But we still have to say: Although the program community has a lot of best practices, such as spring,hibernate, but our system is different, we must not mechanically, the key to open the truth of the lock is always the most appropriate.
The design of the program is an art, most of the problems we face do not have an absolute best superior to all methods. Most of the time, this is the case, the plan is good, then we need to find a "most suitable."
Some of the best practices we can use today include:
always maintain the readability of the program, extensibility, maintainability;
Simplicity is beauty.
Try to use object-oriented thinking
Reduce dependency
Layered development model The basic pattern of web development We talk about is actually layered development pattern.
The so-called layered development model refers to the development of the Java EE program, the entire program according to functional responsibility of the vertical division.
So why layered?
The original driving force of layering is also what we said before about the readability and extensibility of the program.
You can make the program clearer------readable only if you separate the code from the different functions and responsibilities
The similarity function boils down to a portrait once, which makes it possible to study a common solution at this level-----extensible
The most typical partitioning method is to divide the entire program into: the presentation layer (Presentation layer), the business layer, the persistence layer (persistent layers)
As follows:
Different levels, assigning different tasks
Presentation layer: Responsible for dealing with the related functions of user interaction
Business layer: Responsible for business logic calculation and judgment
Persistence layer: Responsible for persisting business data to storage
But when we talk about layering, we have to face two more questions.
Is there a need for layering?
Second, if layered, how many layers?
First of all, if the project is very small, there is no need to layered, that is the saying "kill Chicken with Sledgehammer" "anti-aircraft fight mosquitoes"; however, if the project is large and involved in various aspects, then it is meaningful to use the layered development model at this time.
Second, if layered, divided into several layers? One of the best practices to say is "simplicity is beauty" so we want to make layering simple. But in fact, there is no absolute answer to this question, becauseeverything is out of business. The actual architectural design is illusory.We can only continue to explore in practice, the experience of our predecessors as an important basis for our procedures.
In factThe frameworks we are familiar with are solutions designed for programming problems at each development level.
For example, spring serves the business layer, hibernate serves on the persistence layer, and struts works on the performance layer.
Under the premise of layered development, the MVC pattern can be taken out of each layer to study and find best practices. For the presentation layer, the MVC pattern is widely used, and based on this, many mature frameworks are created.(MVC is a thought, not a technology, it's not code itself, just like the interface we say in the program, remember, it's just a thought)
M (model)----data Model
V (view)----View Display
C (Control)----Controller
The so-called MVC pattern is the problem that is encountered in the development of a program based on the "request----response" pattern through elemental decomposition.
Any one B/s application, its essence is a "request----response" process of the collection body.
Now let's take a look at the "request----response" process.
In the diagram, there are at least three elements that are indispensable:
Data Model:
In the diagram is the data transmitted along the direction of the arrows, they are the core carrier of the program.
External Interaction:
We can understand two parts of me, a "head", a "tail". The head is the beginning of all our requests, there is no head, nothing in the back is to be talked about; the tail is the final act, and we have to tell the observer outside the system what our final execution results are.
execution and control of the program:
It not only accepts the request, but also handles the request, and is responsible for the corresponding jump after processing.
Long ago, we used the servlet as part of the execution and control of the program, and then we had struts to use the action it provided, and maybe a few years later, struts would go down the stage of history, and we would use a new technique to execute and control the program. But if we ignore these outward manifestations, is the interior not MVC?
Data Model-----------M
External interaction-----------V
Execution or control of a program----C
In fact, we have used this very early, and what we lack is just the ability to dig out the concept. Now let's look at a classic MVC model diagram:
All we need to do is give these boxes a different form of representation. In fact, the framework is doing this thing, but the framework in addition to give the above several elements of a certain form of expression, but also solve the various elements of the problems encountered in the run up.
In the next section, we'll forget all the frameworks, implement the MVC pattern in the most primitive way, and talk about some of the problems that the presentation layer encounters.
STRUTS2 Technology Insider Reading note Two basic patterns of web development
