Verification of Framework Design

In the previous article, I mainly talked about whether persistence is required. In fact, at the beginning, I thought that persistence layer was required, as some people say, persistence can enable you to know whether your type and value assignment are correct during compilation. However, using those containers does not allow you to use them. This also shows the benefits of strong types. If a container similar to hashtable is used, the compilation may pass, and the result may be an error while running the program. The use of these containers is good or bad, just as the fish and the bear's paw cannot have both sides, it is difficult to weigh (these problems, you have to ask for advice from the garden's big ox class ). As I have said before, if we use an entity layer, we may use a large number of reflection processes at a high cost. When the framework was not designed for verification, I used the idea of ORM in the first place. When I joined the framework for verification, my idea changed! Let's talk about the design of the verification layer in my framework! Here I will only describe the design ideas, and no source code is provided!

In verification, our web programs may have both ends (servers and clients) to process the same verification. (The reason why I want to process both ends at the same time is that I believe that the sentence "Never trust the data submitted by the customer", so I have to repeat the verification process on the server ), so is there redundancy in the verification at both ends? The answer is obvious. If you write code honestly, both ends must write their own code (JS and CS code ).
Okay, I have written all the code specified by the boss! "Ah? What? ", Suddenly the boss told me," Small S, this verification may not be like this, maybe it is not clear in the document, but it is still necessary to do so... "," Oh, my God! Boss, you should not have said that! ", I thought. But it's okay. Can I just change the JS! Oh, no. There is also a minor procedure on the CS side.
Although there are not many changes here, some programmers will give up (remove) the code verification on the server side. Hey, you can't see it anyway! I just need to quickly meet your requirements! Who taught you to give me the document if you don't want to know it! Deserve it !!! Removing verification from the server may have little impact, but if you encounter malicious code, it will be a good day!
The progress of society has been accumulated from the experience of our predecessors. This is the case with the design model and the experience in writing program code. We learned from falling down again and again how to avoid repeating the same mistake! Can this small verification beat us again? OK, huh, let's go! Let's talk about my solutions to these problems! (It seems like the validate of struts in Java )...
I did this by verifying it in XML (XML is just one of the carriers or databases), And I encapsulated all the common verifications! Let's take a look at the example of this configuration file:

<Field name = "txtcargono" display-name = "goods No." maxlength = "11" type = "text">
<Depend name = "required"/>
<Depend name = "isnumeric"/>
<Depend name = "maxlength" Param = "11"/>
<Depend name = "minlength" Param = "11"/>
<Dpend name = "server" reflect-validate = "exportcargo. cargonumberisexsit" Params-validate = "txtcargono, eg_id"/>
</Field>

The fields indicated by required are required. After the required matches, check whether the isnumeric field is correct and then perform the next step. It is worth mentioning that there is a name = "server", which indicates that even if it is verified on a server side, it is the Ajax asynchronous verification that we have to use. Reflect-validate: indicates the class and method name corresponding to the service layer of the response. Params-validate: indicates the parameters required to verify the response. In this example, we need two parameters: txtcargono and eg_id. txtcargono represents its own parameter, and eg_id represents the ID of the object of the operation (because during editing, in this step, you must exclude your own ID ).
Javascript verification process: the carrier verifies that the XML is cached after it is loaded. Based on the content of the configuration file, the JS Code is automatically generated and cached (because every page verification submission will not change)
CS-side form submission and verification process: when the form post comes in, I will first hand it to validate to remove some special symbols of the form (such as anti-SQL Injection symbols, if it is a common text box, you have to filter HTML). After cleaning it, generate an idictionary <string, string> and check with the document to verify that the elements in it are not within the scope of submission specified in the document. After cleaning again, it will be handed over to the factory of validate. facotry will reflect the CS verification method to be dynamically called Based on the name of depand (such as required). After the call, if the condition is not met, the value does not conform to the scope specified in the document. If yes, as long as my facotry queue is still not empty, I still have to continue validate. In this loop, I quit every time I encounter any non-conforming conditions. Or I quit when I find all the conditions pass. (Note: If the reflection here has to improve the performance, it has to be cached)
Ajax verification on the CS side: Generally, this transfer is also passed through the POST method, and the information entered by txtcargono and eg_id is sent. The subsequent steps are similar to the form submission verification process on the CS side.
Note: The Factory method mentioned here is similar to the JS end.

The article was written in a rush, but there are still a lot of work to do on hand! This is the overall architecture. I don't know what you think about in the garden? Please discuss with you.
Attached test example: http://export.job-mate.com/BookingNote.jobmate? Action = insert



Not complete, To be continued...