ASP. net mvc:-step-by-step Form Verification Framework (2)

Digress: in order not to misunderstand, the things about wheel building are again highlighted at the beginning of this article. If you think that the person who re-creates the wheel is a fool, you can ignore me and my ancillary products directly. the focus of this article is not a verification framework.CodeI just want to talk about how to use dataannotations. Why do I have a long story? If I have read this article carefully, I will know how to use TDD to implement a verification framework, at the same time, it should be as easy to understand as possible. Of course, this does not mean that the wheel created in this article has no value, and others are always others. It is not very complicated to verify the framework, it is not difficult for a single person to make a perfect task. In some cases, it may be difficult to say that it is better than a foreign artillery. In the end, I hope you will show your mercy.
After talking nonsense, I started the text below. The focus of this article is to solve the code flexibility problem in the previous article. In the previous article, we implemented two verification attributes, But we encountered a new problem, the surge in the amount of code in the method and rigid verification methods cannot allow us to flexibly expand the framework. If the framework is poor, it will change and change, so we have to solve this problem. From the current Code perspective, the validate method of an object is obviously problematic. It has too many responsibilities and is bound to be reconstructed. How should we separate the responsibilities?
We can take this into consideration. The current verification attribute only declares the verification parameters. If there are many attribute parameters, the verification modes are also different, so why not let the property verification be self-reliant and self-reliant? Your own restrictions, verify yourself. therefore, considering the extended verification attribute function, since verification is a contract and a public action, we can't avoid designing an interface to take charge of this part. Consider the following interface:

In this way, we can implement the corresponding verification logic in xxxattribute. First, determine the new verification code and perform a comprehensive verification test on the three attributes:

Then we start to refactor the rangeattribute and requiredattribute classes. The following figure shows the verification logic in the two attributes.


Finally, modify the verification method of student to verify each attribute by calling the validate method of xxxattribute.

Then execute the test code-pass, and we are glad that our refactoring is done well, as long as the verification attribute of ivalidationfilter is implemented, it can be automatically verified. (For the code so far, see Leven. validate04 ).
Next, let's consider another question. Our verification method is written in the Student Entity. What if we have another teacher entity? Is it necessary to copy this method in the teacher object? This is obviously not a good method. We should not extract this code in one way, so we can consider the following two methods:
1. Since each object requires this method, it can abstract the object and implement the public base class at the top of it. This method is implemented in the base class.
2. Create an object without modifying it. Cube Method (static method ?? Extension Method ??) For verification
Compared with the above two methods, we can foresee that the second method can establish more extensive verification, that is, it can verify the object, of course, the premise is that the validation attribute has been added to the object (it doesn't matter if it is not added, so the verification will always succeed). Therefore, the second method of verification can be used in any environment for data verification (in fact, dataannotations and other unlimited verification frameworks use this method) the first method seems to have requirements on the entity itself, which will inevitably lead to limitations. However, what we need to consider now is the form entity, that is, it may work with ASP when necessary. net MVC framework can be integrated, which is a limitation. Therefore, the first method is also a good choice, we have defined that only some of the entities we need can enjoy this function. at the same time, if you do not need to consider more cases when integrating with the MVC Framework in the future, you have decided to use the first method.
The first step is to determine the interface, a required ivalidationentity interface, and then the interface must have a default Implementation of validationentitybase. The specific implementation steps are as follows:
1. added the ivalidationentity interface, which contains a validate method.
2. added a validationentitybase class to implement the ivalidationentity interface.
3. Move the code of student's validate method to the validationentitybase's validate method.
4. Create a unit test. The test code is consistent with the previous one.
5. Start the test to ensure that the test passes
Through these steps, we have successfully reconstructed the entity. If we add any new entity, as long as it inherits from validationentitybase, we can enjoy the benefits of verification in the project Leven. in validate05, you can see Source code At the same time, the new entity teacher is implemented and tested.
Summary: Let's look back at the step-by-step reconstruction process of the Framework. From the current point of view, the previous refactoring attempts are all aimed at scalability. This is exactly what the framework and common Program The fundamental difference is that the framework is generalized. Therefore, we have achieved several goals step by step:
1. After the code is completed for the first time, the entity attributes can contain any number of verification attributes.
2. During the first reconstruction, each attribute of an object can have any number of verification attributes.
3. The second refactoring enables each attribute of an object to have any of the two currently supported verification attributes.
4. The third refactoring, separation of verification responsibilities, and addition of the validation attribute Extension function, so that each attribute of the object can have any number of verification attributes that implement ivalidationfilter.
5. The fourth reconstruction, transfer verification method, and add the ivalidationentity interface, so that each attribute of any entity implementing the ivalidationentity interface can have any Multiple Validation attribute implementing the ivalidationfilter interface.
So far, it is really a bit like a framework. Although the above five encoding processes are relatively difficult to say, it is a process of generalization of functions step by step. two important objectives of the verification framework are truly achieved: 1. scalable rules, 2. provides verification services for the objects to be verified, and identifies the objects to be verified.
The class diagram so far is as follows:


Now it seems that the framework can meet our requirements. Is it perfect? Of course not. If you really want to use it in practice, there are many other factors to consider. First, we are verifying that attribute defines an error message, however, at present, we only get one bool value after verification is completed, and we cannot obtain the corresponding verification information. Second, the framework currently uses reflection to verify the data, however, reflection efficiency is always unpleasant. In the next article, we will focus on solving these problems.
Finally, the project file:/files/Leven/levenvalidatelibrary02.rar is provided.