How to design software to avoid problems: data processing web-form

When answering this question it is always necessary to ask yourself the question of software evolution. Which part of the system is most likely to change, and which is likely to remain constant?

We will consider this issue with examples. Consider several tasks that regularly occur in more or less large systems. The reasons for the emergence of this type of tasks are taken out of the scope of this post, but here we stop at the implementation.

Processing web form data

Forms are similar: added one field, removed another, cut down possible values ​​to numbers, made a multiple choice instead of a single one, etc. From the point of view of performance, a minor change. How much does the internal logic change?

')
The first thing that comes to mind when looking at simple forms is to match an object to a form, for each field of the form to provide the corresponding field of the object. When we receive a request, we write all the form fields into the appropriate fields of the object, validate, if there are errors, we give them to the user with fields binding and edit them, if everything is ok, we transfer them for further processing (how it will be processed - this already depends on the task ), if as a result of processing errors occurred - errors were drawn (possibly, together with the form).

We will develop the idea.

Let's look at the evolution of forms. As a rule, there are tendencies to (any combinations are possible):

• Adding new fields
• Remove optional fields
• Context change
• Change the obligation to fill out (both ways)
• Remove required fields (= change required + delete optional field)
• Changing possible field values, including changing the type of values

From here, the following problems may occur:

• Added new field. A set of fields for previously identical forms may become completely different over time.
• Removed any optional field. Just remove the handlers for this parameter. It would be good to clean the table in the database and the code for working with this field, but not critical.
• The field was required, it became optional. Checks on null thoroughly spoil life.
• The field was optional, it became mandatory. The problem is in the existing data: how to process if there is no value, but it is required for the operation?
• Changing possible field values, including changing the type of values. I think the problems are obvious, all the dependencies on the type of field should be changed.

What conclusions suggest themselves?

• Do in the database checks for NULL need only for guaranteed mandatory fields. These are the fields, without which the record in the database loses its meaning. As a rule, these fields are few, and often they represent an alternative key (or its subset). If you do not believe it, try to consider the possibility of introducing anonymous users (that is, users without registration).
• If a set of fields varies depending on the context in forms similar in semantics, depending on the context (for example, the format of the questionnaire for different customers), it makes sense to introduce attribute logic, where one record in the database corresponds to one field value (and not the entire set of form fields).
• If there are a lot of optional fields, and they are intended only for storing any data, it also makes sense to use attribute logic - their set in practice is subject to change.
• If different logic is tied to an optional field in different parts of the system, it makes sense to consolidate it into one place. First, let it be a class with two or three methods - then their number will easily grow to 15-20. This will also help solve a potential problem in the event the field becomes mandatory.
• To eliminate typing problems for each field, we store its type, and always transmitting the value of this field together with a link to the meta information about the field and its type. If you need to share with external systems, we introduce clear rules for serialization (for example, in a string, including in XML) and parsing error handling.
• Regular refactoring requires deleting the old code to work with fields that no longer exist. No comments with code blocks - we will leave history for the version control system.

PS In the following topics we will consider the generation of reports, the analysis of the “raw” data of network protocols and other problems as desired by the habrasoobshchestva.