Single Portal Web Application Overview: structure, features, advantages, disadvantages/php,asp,jsp

Overview of single portal applications

What is a single portal application?

Before explaining what a single portal application is, let's take a look at traditional Web applications.
News.php Show News List
News_edit.php Show News Edit Page
These two pages have not only implemented two functions respectively, but also become the two portals of the application.

What's the entrance?
For example, everyone on the WC, are boys into a door, girls into a door. These two doors are the two entrances to the WC.

Hehe, the above example should be well understood. The concept of a single entry is easy to understand, if you change it a little.
Now we are entering a public WC, where men and women enter from the outermost entrance and pay two doors respectively. The outermost entrance is the single inlet of the WC.

So a single-entry application is essentially a file that handles all HTTP requests. For example, the index.php file is accessed from the browser, whether it is a news list feature or a news editing feature. This index.php file is a single entry for this application.

How does index.php know which feature the user is using?

Very simply, we can follow a specific parameter when we visit index.php. Index.php?action=news, for example, shows a list of news, while Index.php?action=news_edit is a news editor.

In index.php, this effect can be achieved with just two lines of code.
<?php
$action = $_get[' action '] = = '? ' Index ': $_get[' action ';
Include (' files/'. $action. '. php ');
?>

In the above code, the first line is to remove the action parameter from the URL. If the action parameter is not provided, a default ' index ' is set as the parameter.
The second line of code is to invoke different code files according to the $action parameters to achieve the effect of a single entry corresponding to different functions.

The portal file for a single portal application is complex?

Some friends may think that the index.php of a single entry program will be as complex as noodles, but it is a misunderstanding.
For example, my application portal file now has only the following lines:
<?php
Define (' APP ', Realpath ('. /libs/website '));
Define (' LANG ', ' gb2312 ');
Define (' DEBUG ', 1);

Require ('.. /libs/flea1/basic.php ');
Run ();
?>
Simple enough, huh?

Of course, writing a long list of switch case in index.php is definitely a bad way to implement it. But this is purely a developer's own design and implementation problem, rather than a single-entry application of this design idea.

Note: The switch case mentioned here is not to say that the switch is used to represent "backward", "rustic" and so on. Just say that in the index.php this entry program is written in a bunch of switch case is not conducive to program modification and maintenance, so is a bad usage.

When the Web server (Apache or IIS) receives an HTTP request, it resolves the request and determines which file to access. For example, the parsing result of http://www.xxx.com/news.php is to ask the Web server to parse the news.php file and return the results to the browser. Now look at the index.php file for the single-entry application, and you'll find that index.php actually has a second parse based on the URL parameter.

The process of completing this parsing is generally called Dispatcher (I do not know the exact translation of Chinese), presumably meaning that different requests are forwarded to different handlers for processing.

In a single-entry application, index.php and the Web server together form a Dispatcher that determines the requested handler based on the HTTP request and URL parameters.

Having understood the concept of Dispatcher, we can see that the two lines of code mentioned earlier are actually the simplest Dispatcher implementations:
<?php
$action = $_get[' action '] = = '? ' Index ': $_get[' action ';
Include (' files/'. $action. '. php ');
?>

Admittedly, for a secure, robust application, Dispatcher is certainly not as simple as it is. Before invoking the actual code, a variety of judgments, security checks, etc. are added. For example, determine whether the function specified by the URL is accessible and the URL contains invalid parameters.

See here, friends will certainly say: the single entrance procedure is more such a dispatcher, and I directly into the news.php, news_edit.php and other individual files compared to what benefits ah?

Benefits of a single portal application

All HTTP requests for a single-entry application are received and forwarded to the function code via index.php, so we can do a lot of actual work in index.php.

Here I'll just take the safety check as an example to explain in detail:
Because all HTTP requests are received by index.php, a centralized security check is possible. If it is not a single entry, then the developer must remember the security check code at the beginning of each file (of course, the security check code can be written to another file, only need to include in it).
But I think we are lazy people, perhaps the memory is not good, inevitably have to forget the time. So it's not easy to remember to add the necessary include in front of each file.

Similar to security checks. In the portal, we can also make necessary checks and special character filtering for URL parameters and post, log logs, access statistics, and so on, which can be centrally handled tasks.

"Why, do so many functions, will not make index.php very complicated?" ”
"Not at all." Just write the various functions to a separate file, and then include in the index.php! ”

As you can see, these efforts have been focused on index.php to ease the difficulty of maintaining other functional codes. For example, it is not a pleasant thing to keep a few parts of the head in 10 files consistent with each other.

Disadvantages of single-entry applications

There are two sides to everything, and a single portal application is no exception. Because all HTTP requests are for index.php, the URL of the application does not look so beautiful. Especially for the search engine is very unfriendly.

To solve this problem, you can use URL rewriting, PATHINFO, and so on. But I personally recommend not using a single entry method on the foreground page, but rather keeping multiple file portals. or mix them. For example, the news list is displayed by a separate news.php, and the user registers, publishes the information and so on uses the single entrance. Because for the site owner, news list, news display page is the need for search engine attention to high-value goals, and user registration page and other interactive features are not included in the value.

A friend mentioned that a single portal application would have a long list of parameters, so let's analyze the following URL:

Index.php?url=news&news_id=123&page=2&sort=title
If you change to direct access to news.php, you simply omit the url=news parameter.

So it makes no sense to think that a single portal's application URL is too complex.

How do I organize the function code for a single portal application?

The biggest challenge for single-entry applications comes from how to properly organize the processing code for each function. But if you follow a certain step, you can easily solve the problem.

First, make a reasonable decomposition of the functionality of the application. For example, the background news column may contain "Add News", "Edit News", "Delete News" and other features. We can then combine this logically associative set of functions into a functional module called the "News management" module.
By following the above method to finish the application function, we will get multiple function modules, and each module is composed of several functions. (In fact, even if it is not a single-entry application, functional collation is a necessary step.) ）

After finishing the function, we need to determine how to store the code for each function.

Here I recommend two ways:

1, each function module a subdirectory, the directory of each file is a function of the implementation code.
The benefit of this approach is that each feature's code is isolated from each other, making it easy for multiple people to collaborate. The disadvantage is that sharing code and data between each feature is not so convenient. For example, all the functions in the News management module need a "Take out news column record" function, then the use of this multiple independent file organization, "Remove news column Record" Can only be written in another file, and then by the need for the function of the file include.

2. One file per module, each function in the module is written as a function or a class method.
The benefits don't have to be said much, it's easy to share code and data. The downside is that if several people change at the same time, conflict is easy. But with version control software and the diff-diff merge tool, conflicts can be easily resolved.

All right, our function code determines how it is stored. So how do you call it?
index.php How do I invoke the function code?

The first call is to design a rule, and then let index.php search for and invoke the function code according to this rule. For my own part, I always use $_get[' url ' to specify the function module to invoke, and $_get[' action ' to specify the specific functionality of the module. So my application will use the following URL address:
Index.php?url=news&action=edit

Think two parameters are too many? That can use URLs such as Index.php?func=news.edit. Just take news.edit apart as news and edit.

"Hey, I'm going to do a index.php?url=news&action=xxx to see if your app can run?" ”
Obviously, such a URL will only make index.php unable to find the required function code, and finally report the error. But what is the essential difference between this and your browser's access to the newsxxx.php file that doesn't exist?

Instead, I can let index.php display a nice error page when they find that they can't find the function code they need, and provide a link back to the homepage of the site.

In actual development, I tend to extract some basic services from the application to form an application framework . This framework typically includes a Dispatcher, basic database Access Service, template engine, common accessibility, and so on. With a framework, I can make Dispatcher more flexible. For example, permission checks can be applied to some feature modules, while others are not checked.
Learn more about single entry applications

To understand a thing profoundly, it is the best way to try it yourself.

You can choose to implement a Dispatcher and the corresponding rules, or choose an existing application framework. But the better way is to try out the existing framework first, and then try to implement a similar one yourself. This will get the most harvest in the shortest time possible.

The vast majority of PHP application frameworks are now single-entry and adopt the MVC pattern (unfortunately, because MVC is too complex and not necessarily associated with a single portal application, I won't go into it.) Interested friends can google the relevant information).

Reproduced in http://blog.path8.net/archives/2528.html

Single Portal Web Application Overview: structure, features, advantages, disadvantages/php,asp,jsp