【文章內(nèi)容簡(jiǎn)介】 the Model Center and Model layer pletes the defined transaction logic by calling the given module. Model Database contains a mass of objects and modules. These objects and modules encapsulate the responding methods relative to specific transaction logic. When Model Center receives the transaction messages from Messenger, it selects suitable objects or modules according to the different transaction logic encapsulated in the message. Then it encapsulated the handled data in given format and delivers them to the LPM Center. Furthermore, each object or module only needs to concern how to implement the given transaction logic and how to obtain the necessary data without concerning the presentation of these data. Lastly, we concern the LPM Center and LPM Database. LPM is a set of programs to implement the presentation for a certain data type. It can correspond to a disk file or a set of disk files. On the other hand, a certain Web page can contain one logical page or multiple logical pages. To a LPM, its function is very simple: it only need to present the given data type without being notified any transaction logic and without concerning the source and content of the data. Thus, in the practical development, the LPM is developed by such technologies as label library (JSP) or data binding (.Net). Furthermore, this type of server scripts can be easily understood by the client developers during the UI (user interface) design period and can be developed by some whatyouseeiswhatyouget (WYSIWYG) tools. In this portion, LPM Center receives the data from the Model Center. It selects the suitable logical page module according to the given data type and transaction logic, then it encapsulates the output of logical page module into HTTP response and sends the response to the client. Note that among these three control objects, except SYSController,the other two do not directly access the their own kernel databases. For example, Model Center does not directly call the objects or modules in the Model Database. It implements the access through the ModelFactory class instead. (Showed in figure 2) According to the analysis of this system frame, we can see that the whole system perfectly conforms to the MVC design pattern. During the system development period, there is no distinct interactive relationship among the developers in each part. As long as the system frame is established, the development of each part can be preceded in parallel. It is impossible for the Web application developers to use this approach in the past. Because we have divided the Controller into three parts, the couplings of MVC three layers (Model/View/Controller) bee looser than ever. So it can improve the scalability of the whole system significantly. In the following section, we will show you a simple example to explain how to expand the system frame by adding intermediate transaction processes among the threelayer MVC pattern. 4. Relative problems Examining the present Web application design patterns (such as CGI, JSP MODEL 2, etc.), we can gain an elementary result: Web application system developed by MVC pattern excels the one developed by other patterns at the system logical frame, parallel cooperating development, system scalability and maintainability. It is mainly due to the deficiencies of the old design patterns on system logical frame partition. For example, in Web systems developed by CGI, the CGI programs not only need to process the transaction logic, but also are responsible for the system presentation format. Therefore, it requires the developers to have very powerful programming ability (they have to be very familiar both with the transaction programming and the interface designing). In addition, it even makes the system logic and hierarchy chaotic. At last the chaotic codes will lead into a series of problems. Using the server script languages (such as ASP, PHP, etc.) to implement Web application systems is also not satisfactory. The reason is that the script languages have innate deficiencies (for example, they do not have good object supporting and event response mechanism)。 they cannot satisfactorily encapsulate the transaction logics of Web application systems. The deficiencies of JSP Model 2 have been described in the above part of this paper, so it has no need to be presented in here again. 5. Conclusion From the analysis of the system frame above, we can draw a conclusion. The improved Web application system frame based on MVC design pattern has clearer structure than traditional ones. The couplings among each module are looser. Especially, this frame resolves a big problem, which puzzled Web developers for a long time. It separates the transaction logic from presentation, and implements the parallel proceeding in development. Furthermore, by using the Model Database and LPM Database, the flexibility, maintainability and scalability of the whole system have been improved greatly. The frame discussed in this paper has been applied in the web application system of UEST of China ( References [1] Erich Gamma. Design Patterns. . AddisonWesley Pub Co. [2] Didier Martin. Professional XML. . Wrox Press. [3] Stephen T. Mohr. Designing Distributed Applications with XML, ASP, IE5, LDAP amp。 MSMQ. . Wrox Press. [4] Sun Microsystems Inc. JavaTM Servlet and JavaServer PagesTM Spec fications. [5] Sun Microsystems Inc. JavaServer PagesTM Standard Tag Library Specification 譯文二： 網(wǎng)站建設(shè)技術(shù) * 網(wǎng)絡(luò)技術(shù)的發(fā)展 ,為今天全球性的信息交流與資在建立源共享和交往提供了更多的途徑和可能。足不出戶便可以知曉天下大事 ,按幾下鍵盤(pán)或點(diǎn)幾下鼠標(biāo)可以與遠(yuǎn)在千里之外的朋友交流 ,網(wǎng)上通信、網(wǎng)上瀏覽、網(wǎng)上交互、網(wǎng)上電子商務(wù)已成為現(xiàn)代人們生活的一部分。 Inter 時(shí)代 , 造就了人們新的工作和生活方式 ,其互聯(lián)性、開(kāi)放性和共享信息的模式 ,打破了傳統(tǒng)信息傳播方式的重重壁壘 ,為人們帶來(lái)了新的機(jī)遇。隨著計(jì)算機(jī)和信息時(shí)代的到來(lái) ,人類社會(huì)前進(jìn)的腳步在逐漸加快。近幾年網(wǎng)頁(yè)設(shè)計(jì)發(fā)展 ,快得 人目不暇接。隨著網(wǎng)頁(yè)設(shè)計(jì)技術(shù)的發(fā)展 ,豐富多彩的網(wǎng)頁(yè)成為網(wǎng)上一道亮麗的