Thinking about three kinds of mainstream web architecture-application Skills

The following ideas are mainly implemented as examples in PHP, but many of the experiences I think Java,.net,ruby developers should also be easy to understand. Finally, I have just published on the number of people concerned about the Delphi fo PHP evaluation.

The architecture of a Web program can basically be grouped into three categories:

(i) based on "Web pages/Files", such as CGI and php/asp programs. The program's files are stored in separate directories, corresponding to URLs. When an HTTP request is submitted to the server, the URL points directly to a file, which then processes the request and returns the result of the response.

Like http://www.website.conm/news/readnews.php?id=1234.

As you can imagine, we place a readnews.php file under the News directory in the root directory of the site.

This type of development is the most natural, easiest to understand, and also the most common way of PHP. Note that the resulting URL is unfriendly to the search engine, but you can use the URL rewrite scheme provided by the server, such as Apache Mod_rewrite.

(ii) based on "action". This is the most common way to use the Web application of the MVC architecture. The current mainstream web framework is designed like struts, webwork (Java), Ruby on Rails (Ruby), and Zend Framework (PHP). The URL maps to the controller (Controller) and the Action (action) in the Controller, and the action handles the request and outputs the result of the response. This design, like the file-based approach above, is a request/response-driven scenario that cannot be separated from HTTP.

Like http://www.website.com/news/read/id/1234.

You can imagine in the actual code, we will have a controller newscontroller, which has a readaction. Different frameworks may be implemented in a slightly different way, with a controller of one file, multiple action, and one file per action. Of course, you can control this by yourself, digression.

URLs in this way are usually pretty and search engine friendly, since many frameworks have URL rewriting capabilities. You can freely specify where controller, action, and parameters appear in the URL.

In addition, there is a more direct URL based design, that is rest. By artificially restricting the form of URLs (such as action limited to only a few) to facilitate mutual access between sites, reduce the complexity of development, improve the scalability of the system. Rest is an innovation for Web services.

While this article discusses the architecture of a single project and rest is designed to address communication problems between Web sites, the presence of rest can have an impact on the architecture of a single project (it is clear that you will construct the canonical URL when you develop it). It should also be a trend to mix rest and MVC in the future. ROR provides good rest support, and the Zend framework also provides zend_rest to support rest, including server and client.

(iii) based on "Components" (Component, GUI design is often called control), event-driven architecture, the most common is Microsoft's. NET. The basic idea is to divide the program into components, and each component can trigger events and invoke a specific event handler (such as setting the OnClick event on an HTML button to link to a PHP function). This design is far from Http,http request complete abstraction, mapping to an event.

In fact, this design is most commonly used in the development of traditional desktop GUI programs, such as Delphi,java swing. All performance layer components such as Windows, or HTML forms can be provided by the IDE, we only need to click or drag the mouse in the IDE can automatically add a component, and add a corresponding event handler.

This development approach has several advantages:

Reusability-code is highly reusable.

Easy to use-typically you only need to configure the properties of the control to write related event-handling functions.

I kind of like it, too. Pear provides a fairly powerful html_quickform for adding form elements and their event handlers to the page, as well as for combining template engines such as Smarty. This is a complementary feature for project development, where some parts of the project use Quickform and sometimes can greatly accelerate development.

A fully component-based and event-driven development framework is also not new to PHP, Prado is a framework that once won the first prize in the Zend Programming competition. But for now, it's clear that Prado's approach to development is still not accepted by most PHP programmers. Why, then?

I think there are the following two main questions:

(1) Efficiency problems

This refers not to development efficiency, but to the execution efficiency of the code. As we all know, PHP's execution is fairly efficient under normal circumstances. But the effectiveness of this control-based framework is problematic at the moment. The Prado itself provides a caching mechanism to mitigate this problem. If the cache is not used, it can be said that many sites do not use Prado such a framework, such as portals, large forums and so on.

But ASP.　NET is not the same, because it is a compiled framework, the last generated code is compiled, do not need to do a lot of intermediate process of processing, so the first execution after the speed will be very high execution efficiency. This is the language level function, Prado cannot be completely compensated through the effort of the code level.

(2) No strong IDE support

Setting the properties of the control, adding its corresponding event handler, seems simple, but it's a lot of control, and it's also a heavy task. NET is so powerful that it frees programmers from repetitive work, and it's convenient to set properties, and event handlers are added automatically. Prado currently does not have such IDE support.

In a word, the control based framework is more suitable for user interaction, it needs to set up different processing operations for many components in the page, but not for the application of high performance requirements. In addition, frameworks with component support are usually better supported by Ajax, for example. NET and Ruby on Rails.

In summary, the three architectures can basically represent all the current mainstream web development methods, including Php,javaee,.net,ruby/ror.

Current situation of PHP development and future trends:

Usually do PHP more, especially summed up the trend of PHP development. Currently in the PHP development, we are most commonly used is based on the "file" architecture, in fact, is a "process-oriented" approach to development. Usually the purpose of writing PHP programs is to "come online and let the program run". And most PHP programmers and HTML, CSS to do close combat, so if the program is too abstract, adjust the visual effect is more difficult. So for small projects, this is one of the best options.

But more and more people are recognizing that object-oriented and MVC frameworks are more likely to facilitate code reuse and sharing, and that programs are easy to scale, and that the trend becomes more apparent as program complexity increases. So the OO framework is endless. The most promising of the current PHP framework is the cake, symphony and Zend frameworks, each with an active community and a large user base, all growing rapidly. The PHP framework avoids the huge, bloated Java framework that is dedicated to rapid development, and actively mimics and absorbs new features of these ROR frameworks. With the popularity of PHP5 and the maturity of these frameworks, and the large number of people who originally developed a community in PHP, some industry standards may be produced in the future.

This choice is appropriate for medium and large projects, especially the need for greater teamwork and long-term maintenance and two development scenarios. Personally think this is the future trend of PHP development.

Most PHP programmers are not interested in component-based and event-driven development methods. But there are a lot of people in the effort to do this, such as CodeGear Delphi for PHP, attracted a lot of people's attention. If there is strong business support, perhaps in the future development of the market will also occupy a place.

I will introduce the new features of d4p and evaluate them in the next article.

Future prospects for Web development:

With the popularity of rest that is closer to HTTP, I feel like. The way in which abstract components in net and Java are impacted. Because these components are not as convenient as they are promised. The future Mvc+rest+ria model should be more popular.

Ajax is a double-edged sword, although the event-driven architecture looks great for processing asynchronous requests (imagine that there are several components in the page, that each component can trigger an asynchronous request, and it looks like an ideal way to handle an event handler on the server side), However, it is not easy to generate good JavaScript code for the client, to meet the compatibility requirements of various browsers, but also to be able to expand their own to meet the strange needs of the project. Most of the time I prefer to use some JS framework such as prototype to develop their own effects, rather than on the server side of the build. Generate JS on the server side of the two results, one is the generated code distrust, and two people become stupid, because you do not know what really happened.

(A little grumbling is posted)

Personal doubts about web development:

• In order to make development simpler, we have to learn to use complex development tools and frameworks, is this an improvement or a setback?

Does the IDE make programmers smarter or dull? When we can design the client interface in the server code, is this an improvement or a setback?

Microsoft's ASP.net AJAX, for example, allows us to design a variety of asynchronous controls on the server side. So programmers can not even JavaScript, do not know Ajax to design a variety of client effects.　What do you do if a project needs to be designed with a slightly more complex effect and the IDE and the framework can't do it automatically? By this time again to learn JS, maybe late. What is more frightening is that technology in the update and elimination, may be ten years later, you will find yourself in addition to a variety of Ides, really proficient in the technology is very few, out of the IDE you write a small program to check half a day API manual, because you usually rely on "automatic completion" to write code! Such a scene, I think no one wants to happen.

It may be a step forward for a short-term development project, but it's not a good thing for a programmer's personal growth. The reliance on tools has led to a superficial understanding of the underlying and core technologies, limiting the growth of individuals.