SEO impact site Structure and weight

&http://www.aliyun.com/zixun/aggregation/37954.html ">nbsp; Web site size to a certain degree, the code of various logic entangled together, will give maintenance and expansion of a huge obstacle, then our solution is actually very simple, that is refactoring, the logic of layering. Usually, Top-down can be divided into performance layer, application layer, domain layer, persistence layer.

The so-called performance layer, not only refers to the template, its scope to be more extensive, all the logic related to the performance should be included in the scope of the performance layer. For example, where the font to be shown as red, somewhere at the beginning of the two space, these are the performance layer. Most of the time, the mistake we make is to put the logic that belongs to the presentation layer on the other level, here is a very common example: when we display the title of the article in the list page, we set a maximum number of words, and once the length of the title exceeds this limit, it is truncated and the "..." is shown later. This is the most typical expression layer logic, but in fact, many programmers are in the non-performance layer of code to complete the data acquisition and truncation, and then assigned to the presentation layer template, the most direct disadvantage of such code is the same piece of data, in this page I might want to display the first 10 words, and then another Page I might want to display the first 15 words, and once we've cured this word in the program, we're losing portability. The right thing to do is to do a program such as a view helper to deal with this kind of logic, for example: the truncate in Smarty belongs to the View Assistant (but the implementation is not suitable for Chinese).

The so-called application layer, its main role is to define what users can do, and the results of the operation feedback to the performance layer. As for how to do it, it is usually not the scope of its responsibilities (but the domain-level area of responsibility), and it will be delegated to the domain to deal with the work. In a Web site that uses the MVC architecture, we can see a url:domain.com/articles/view/123 like the one below, with an internal code implementation, typically a articles controller class with a view method, which is a A typical application-tier operation, because it defines the action that a user can make a view of. In the MVC architecture, there is a guideline that says: Rich Model is a. The implication is that controller to keep "thin" some better, and then explain the application layer to be as simple as possible, do not include the logic involved in the domain content.

The most straightforward explanation for the

Domain layer is the layer that contains the domain logic. It is the soul of a software. Let's take a look at what's called domain logic, to put it simply, the logic of a well-defined domain concept is domain logic, such as the way we take money from ATM machines: Insert a UnionPay card, enter a password, enter a withdrawal amount, make sure, take the money, and then the ATM spits out a trading slip. In this process, UnionPay card in the ATM machine to complete the transfer of money from the account of the process is a domain logic, because the money in the bank is a clear concept of the domain, and ATM spit out a transaction by the bar is not the domain logic, but only an application logic, Because it is not a clear domain concept in the bank to spit out the trade bar is just a technical means, corresponding, we take money do not spit trade, and send a reminder message is also possible, but not necessarily so, if in fact, we request to withdraw after the transaction by the article, In other words, spit out the trade with the withdrawal of the bond has been closely linked, then you can also spit out the transaction by the bar as part of the logic of the domain, everything depends on the specific circumstances of the problem. In Eric's classic domain-driven design, the domain layer is divided into five basic elements: Entities, value objects, services, factories, warehousing. You can refer to the introduction in the book. The most common mistake in the domain layer is to divulge logic that belongs to the domain layer to other levels, for example, in a CMS system, the definition of a popular article is this: more than 1000 times a day, the number of comments more than 100 times, such articles are hot articles. For a CMS, the word hot article is undoubtedly an important domain concept, so how do we implement this logical design? You might give a code similar to the following: "SELECT ... From ... Where browse > 1000 and comments > 100 "Yes, this is the simplest way to implement it, but here's the important area of" more than 1000 visits per day, more than 100 times commented, "which is hidden in the SQL statement, The SQL statement obviously does not belong to the domain layer, that is to say, our domain logic is compromised.