Asp.net MVC requires form in Django

in Web development (including Asp.net, fill in the fields of an object instance (corresponding to a table in the database) to the page. After the page is submitted, the values in the control are refilled to an object instance. The input is verified before submission. For example, the user information details display/modification function. Of course, there are still the following requirements in practice. When you change the user password, you need to enter it again for verification. Instead of directly storing the password in the database, You Need To Perform Hash encryption. In the past, I encountered such problems. I often used reflection to fill in the interaction between objects and page controls. In most cases, this is okay, but it lacks flexibility and the logic is unclear. For example, entering the password again is definitely not a field in the database table. It is only a logical auxiliary field, but I must ask for it. Therefore, the userinfo object contains a field such as pwdconfirm, and uses attribute to identify whether it is a database table field. Obviously, this method tastes bad. In addition, in actual development, the logical auxiliary fields required by an entity class in different scenarios are not the same. Sometimes, the verification requirements for fields required or not are different. Therefore, it is impossible for us to stick to the entity class to solve all applications from the UI to the database, but it is much better to introduce an indirect concept form object.

In Django, form is an "entity class" customized for a page or application scenario. It has its own fields, verification methods, initial values, UI control types, and so on, the benefits of doing so are obvious. Verification and UI display are very flexible, and it is not difficult to replace form objects with one entity. A little bit of trouble is that we need to define a form as needed, such as loginform and userform. Although these two forms are used to process user-related logic, login is a different scenario, displays user information. Although it is a little troublesome, this price is acceptable because you can manually define fields in form or generate form objects based on existing entity classes. In the design pattern, M generally refers to a domain object, which should not be exposed, and the transfer object between C and V should be form obj. In our system, the V layer may include web, winform or Silverlight. Our form OBJ can generate different appearances based on different requirements of V. This cannot be solved by a single entity or domain object.

Sigh, form is simple and practical and does not require the support of specific syntax (of course in. net is more difficult to implement than python, and C #3.0 is more convenient.) Why did I not expect it? It seems that I have to wait for a small ball to slowly understand the ideas of masters.