MU-Class Network-java high concurrent second Kill API Web Layer-summary __web

1.DTO

DAO is called data Access object
The DTO is a data transfer object
DAO is often manipulated by objects, such as data in a relational database, that are not object-like.
The DTO is typically used for direct data transmission at different layers (UI layer, service layer, or domain model layer) to isolate different layers and reduce coupling between layers
It's supposed to be Java beans for Jackson and XStream.

2.js to be modular when writing

Object

The object's writing is created, and all module members can be encapsulated in an object

var mymodule = {
    var1:1,

    var2:2,

    fn1:function () {}

    ,

    fn2:function () {

    }
}

So we reference the corresponding file when we want to call the module, and then

Mymodule.fn2 ();

This avoids the variable pollution, as long as the module name is guaranteed to be unique, while the members of the same module also have a relationship

Seemingly good solution, but also flawed, external can be arbitrarily modified internal members

MYMODEL.VAR1 = 100;

This creates an unexpected security problem and executes the function immediately .

You can achieve the purpose of hiding details by executing the function immediately

var MyModule = (function () {
    var var1 = 1;
    var var2 = 2;

    function fn1 () {

    }

    function fn2 () {

    } return

    {
        fn1:fn1,
        fn2:fn2
    };
}) ();

This way, outside the module, we can't modify the variables and functions we haven't exposed.

The above approach is our modular basis, at present, the prevailing JavaScript module specifications are mainly two: Commonjs and AMD Commonjs

Let's start with COMMONJS, because there's no modular programming at the end of the page, just a page JavaScript logic, but it can work, but it has to be a module on the server, so while JavaScript has grown over the web for so many years, The first popular modular specification is brought by server-side JavaScript applications, and the COMMONJS specification is carried forward by Nodejs, marking the formal stage of JavaScript modular programming.

Defining modules
According to the COMMONJS specification, a separate file is a module. Each module is a separate scope, that is, a variable defined within the module that cannot be read by another module unless it is defined as a property of the global object

Module output:
Module has only one exit, Module.exports object, we need to put the contents of the module want output into the object

Load module:
The load module uses the Require method, which reads a file and executes it, returning the Module.exports object inside the file

See an example

Module definition mymodel.js

var name = ' Byron ';

function Printname () {
    console.log (name);
}

function Printfullname (firstName) {
    console.log (firstName + name);
}

Module.exports = {
    printname:printname,
    printfullname:printfullname
}

//load module

var Namemodule = require ('./mymodel.js ');

Namemodule.printname ();

Different implementations of the require when the path has different requirements, the general situation can omit JS extension, you can use the relative path, you can use the absolute path, and even can omit the path directly using the module name (provided that the module is the System built-in module)

3.Restful Interface

Get (SELECT): Remove a resource (one or more items) from the server. POST (Create): Creates a new resource on the server. Put (update): Updates the resource on the server (the client provides the complete resource after the change).

RESTful maintains the state of the resource without having to maintain the client state. For it, each request is new, and it only needs to be done for this request, and there is no need to record the relevant information for this request for subsequent processing from the same client request.

For these features of the restful we've described above, they're all about asking us to do something to satisfy these features, but this stateless thing is asking us not to do anything because HTTP itself is stateless. For example, a Web page obtains records that meet the query criteria by calling the Web API paging page. In general, page navigation has a previous page and a next page link to render a record of the previous and last pages of the current page. Now there are two implementations that return the records on the next page. The Web API not only defines actions related to data query definitions based on specific page numbers, but also defines individual actions for requests such as previous page and next page. It itself saves the page that is returned by each data based on the client's session ID, so that you can know which page the previous and next pages are specific to. The Web API defines only the actions related to the data query definition based on the page number, and the page number of the current returned data is maintained by the client.

The first seems to be "smart", in fact, is a way to gild the lily, because it destroys the Web API stateless. Designing a stateless Web API not only makes the Web API itself simple and concise, but also allows us to effectively implement load balancing by reducing the affinity for clients (Affinty), because only so each server in the cluster is equivalent to each client.