Fix section "Application flowchart" in 13.1.md
This commit is contained in:
24
en/13.1.md
24
en/13.1.md
@@ -16,24 +16,24 @@ Figure 13.2 The working directory under $gopath/src
|
||||
|
||||
## Application flowchart
|
||||
|
||||
Blog system is based on the model - view - controller of this design pattern. MVC is a logic of the application layer and the presentation layer separation is structured. In practice, due to the presentation layer separate from the Go out, so it allows your page includes only a small script.
|
||||
Our blogging system will be based on the model-view-controller design pattern. MVC is the separation of the application logic from the presentation layer. In practice, when we keep the presentation layer separated, we can drastically reduce the amount of code needed on our web pages.
|
||||
|
||||
- Models(Model) represents the data structure. Generally speaking, the model class will contain remove, insert, update database information, etc. These functions.
|
||||
- View(View) is displayed to the user's information structure and style. A view is usually a web page, but in Go, a view can also be a page fragment, such as page header, footer. It can also be an RSS page, or any other type of " page ", Go template package has been implemented to achieve a good part of the View layer of functionality.
|
||||
- Controller(Controller) is a model, view, and anything else necessary for processing the HTTP request intermediary between resources and generate web pages.
|
||||
- Models represent data as well as the rules and logic governing it. In General, a model class will contain functions for removing, inserting and updating database information.
|
||||
- Views are a representation of the state of a model. A view is usually a page, but in Go, a view can also be a fragment of a page, such as a header or footer. It can also be an RSS feed, or any other type of "page". Go's `template` package provides very good support for view layer functionality.
|
||||
- Controllers are the glue logic between the model and view layers and encompasses all the intermediary logic necessary for handling HTTP requests and generating Web pages.
|
||||
|
||||
The following figure shows the framework of the project design is how the data flow throughout the system:
|
||||
The following figure is an overview of the project framework and demonstrates how data will flow through the system:
|
||||
|
||||

|
||||
|
||||
Figure 13.3 the frame data stream
|
||||
Figure 13.3 framework data flow
|
||||
|
||||
1. Main.go as an application portal, running blog initialize some basic resources needed, configuration information, listen port.
|
||||
2. Check the HTTP request routing function, based on the URL and method to determine who( control layer ) to process the request forwarding resources.
|
||||
3. If the cache file exists, it will bypass the normal process execution, is sent directly to the browser.
|
||||
4. Safety Testing: The application before the call controller, HTTP requests, and any user submitted data will be filtered.
|
||||
5. controller loading model, core libraries, auxiliary functions, as well as any treatment other resources required for a particular request, the controller is primarily responsible for handling business logic.
|
||||
6. Output view layer rendering good to be sent to the Web browser content. If on the cache, the cache is first view, the routine for future requests.
|
||||
1. Main.go is the application's entry point and initializes some basic resources required to run the blog such as configuration information, listening ports, etc.
|
||||
2. Routing checks all incoming HTTP requests and, according to the method, URL and parameters, matches it with the corresponding controller action.
|
||||
3. If the requested resource has already been cached, the application will bypass the usual execution process and return a response directly to the user's browser.
|
||||
4. Security detection: The application will filter incoming HTTP requests and any other user submitted data before handing it off to the controller.
|
||||
5. Controller loads models, core libraries, and any other resources required to process specific requests. The controller is primarily responsible for handling business logic.
|
||||
6. Output the rendered view layer to be sent to the client web browser. If you turn the cache, the first view is cached for future routine request.Output changes to the view layer by rendering content to be sent to the Web browser. If caching has been enabled, the first view is cached for future requests to the same resource.
|
||||
|
||||
## Directory structure
|
||||
|
||||
|
||||
Reference in New Issue
Block a user