Webform and monorail

The webform mentioned in this Article refers to the component-style development method similar to winform proposed by Microsoft on the. NET platform. All controllers refer to the Controller in monorail rather than the Controller in MVC.

The development concept of webform originated from winform, controls-based drag-and-drop and backgroundCodeDeveloped in a convenient and quick way. The success of winform demonstrates this point. The core of the whole webform is the control, which exists for the purpose of encapsulating the hand and reusing it, making webform extremely easy to use. This is a convenient and quick development method for webform. netEnterprise developmentThe field has achieved great success.

HTTP is stateless. To maintain the control status like winform, webform has to rely on viewstate/PostBack mechanisms.In general, webform is composed of controls based on the viewstate and PostBack mechanisms. Without them, webform cannot be called webform..

However, the HTML code generated by controls is difficult to maintain while the control is convenient. viewstate facilitates State maintenance and also causes performance loss; one thing that puzzles me about the PostBack mechanism is that, in many cases, we need to determine whether to perform initialization (such as binding actions) for the first request on page_load ). Why does Microsoft not add one more on the page?Events such as initializeTo replace the existingDetermine ispostback in page_load. In this way, it will be more elegant and more like winform.

Let's take a look at aspx and CS. They are webform.PerformanceAndCodeForm of separation, yes, justPerformanceAndCode. The control above aspx depends on the CS control in the background, while the Cs in the background depends on the existence of Aspx. Separation is physical, and logically they are closely integrated. No one else can. Specifically, they are coupled.

In the enterprise development field, because the software will be used within the enterprise within a limited scope, there is usually no too high requirement on the interface, and most of the time it is the interface that developers directly spell out. Therefore, the code generated by webform is no longer disgusting and difficult to maintain, and aspx/CS coupling is no longer serious. The performance loss caused by viewstate/posback is not prominent in enterprise applications with a limited number of users. Therefore, use webform instead.Part 1 Enterprise CS(Client/Server) application advantages are obvious. For example, you only need to update the server when updating the system, instead of distributing the client each time.

However, after all, not all people who use. NET are doing enterprise development.Website developmentI feel like a cow. In the world of website development, our guests usually have requirements on the interface, and sometimes even require the generated HTML code to comply with W3C standards ...... Therefore, the control of HTML code becomes important. On the other hand, the performance overhead brought by viewstate/posback cannot be ignored as a website on the Internet for public browsing; aspx/CS coupling prevents them as designers andProgramEmployeeSeparation of duties(Especially when the programmer throws control such as sqldatasource on the page ).

It is not impossible to kill chickens, but many people are not used to kill chickens with a knife. MVP (Model-View-presenter) is the development method that suits the actual situation of website development. Although webform is much more powerful than monorail, it is not suitable for website development.

Monorail is an MVP development framework suitable for website development. Different from webform's development philosophy, it focuses onSeparation of duties. When the controller (presenter in monorail called Controller) and view are cut and isolated, the division of labor between designers and programmers is also harmonious.Become possible(There is no absolute thing in the world ). In MVP's philosophy, there are no controls, no posback, and of course no viewstate, the communication between the client and the server returns to the original form/querystring/cookie method (isn't it more natural ?), With this, the designer regained control of the HTML code. Programmers focus on data processing in the Controller. After learning simple templates to control code, designers (I usually think designers should have some HTML knowledge, the template file will become his sphere of influence.

Contoller and view communicate with each other through loose propertybag, unlike ASP/cs of webform (CS will reference the control on aspx, or the control on aspx is bound to the data produced by CS ). Therefore, the view has absolute control over the rendering logic, and the modification and adjustment on the view alone will not affect the controller. Even if the designer deletes all the views, the program will not go wrong, so you no longer have to worry about the designer's mistakes. The modifications that should have been completed by the designer do not need to be done by programmers.

Whether it's webform or monorail, the biggest difference is their philosophy. In fact, as long as you have a good awareness, webform can also well separate the interface and control. On the contrary, in the Controller of monorail, HTML code can be generated and then transmitted to the view ......

 

Append two demos that use webform and monorail to implement the shopping cart function.

Shopping Cart (webform)

Shopping Cart (monorail)