A record about checking class property values [knowledge point Attribute], attribute value Attribute

A record about checking class property values [knowledge point Attribute], attribute value Attribute

I haven't come in for a long time. I used to write a blog and record my experience as a code Porter. But after just a few days, I gave up! Indeed, there is no difficulty in the world, as long as you are willing to give up! Haha ...... If you don't talk much about it, you can start to get started and take notes for yourself to avoid getting old and having no memory. You can open it. I also want to give some tips to anyone who can see this article. Of course, this article may not be the best. Maybe I didn't talk about the idea, you guys, Hai Han!

Background: A function has been developed recently. When shipping cargo, a shipping agency needs to send the cago information to airlines in the form of EDI. If you do not know EDI, you can make up your mind (www.baidu.com). As you are new to this industry, you do not dare to explain it yourself. I believe you will write a blog about EDI one day.

When sending edi, the agent company needs to verify the EDI information. If the information is incomplete, the operator must be prompted which information has no value. Therefore, Property Verification is a standard task for developers. Some may say that if else is the simplest and most crude method to directly judge the EDI information attributes. Of course, you can do this if your EDI information class is not very large. Although it is not particularly good to use if else in this way, as long as it can solve the problem, right. We do not advocate such a simple and rude process, a program or a function. if there are too many if else, I think it is inappropriate for people outside the industry. An EDI file is a bit large. Currently, the EDI file I have come into contact with consists of at least 80 classes, each of which has dozens or even dozens of properties, in this case, if we use if else, we have to vomit blood.

That's a bit of a line. You're stupid. You use reflection. In this way, you can judge every attribute of each class! That's right. It makes sense, in uppercase. Reflection is acceptable, but EDI information does not need to be fully verified. What should you do? For example, if you only make a non-empty judgment on important information and pass the judgment on unimportant information, then the protagonist will come, that is, the Attribute feature.

I will not introduce the Attribute. I don't know much about it, but I just need to use it. I suggest you take a look at the introduction of sdn.

Back to the above topic, some fields need to be verified, and some fields do not need to be verified, so I have customized an AttributeProperty class, which must inherit System. Attribute. Then we add the attribute tags we need in the Custom class. For example, if I only need to determine whether this field needs to be verified, I will customize a bool type attribute. If it is false, verification is not performed. If it is true, verification is performed.

1 public class AttributeProperty: System. attribute 2 {3 private bool value; // indicates whether to accept validation 4 public bool Value 5 {6 get {return this. value;} 7 set {this. value = value;} 8} 9 10 public AttributeProperty (bool value) 11 {12 this. value = value; 13} 14 15}

View Code

Then we add a tag on the class attribute to be verified.

Private string authorisation; [XmlElement (ElementName = "Authorisation")] // 1st tags [AttributeProperty (false)] // 0th tags public string Authorisation {get {return authorisation ;} set {authorisation = value ;}}

Here, we need to explain that the annotations are marked with 0th tags and 1st tags. I also found in debugging that when you add features to properties, when the common language runs, it will be automatically sorted based on the features you have added. For better understanding, I call it the proximity principle. The attribute-based sorting starts from 0, in this way, you should understand the meaning of my comment.

[AttributeProperty (false)] this small piece of code is our custom Attribute class. Then, through reflection, we can determine whether the Attribute feature mark needs to be verified.

The code for retrieving field attributes through reflection is as follows:

Type type = obj. getType (); PropertyInfo [] ptys = type. getProperties (); for (int ptIndex = 0; ptIndex <ptys. length; ptIndex ++) {object [] arry = ptys [ptIndex]. getCustomAttributes (false); if (arry. length> 1) {// if the custom property value is false, if (ptys [ptIndex]. getCustomAttributes (false) [0] as AttributeProperty ). value = false) {continue;} else if (ptys [ptIndex]. getValue (obj, null) = null | ptys [ptIndex]. getValue (obj, null ). toString () = "") {// The empty field is saved to the listFiled set in the list. add (ptys [ptIndex]. name );}}

 

 

The above code is a bit lazy and does not have good control over the obtained features. It gets the feature tag of the attribute through reflection. If it is true, it is not null to judge, if it is set to false, non-null judgment is not performed.

The above text only belongs to personal notes and records. It would be coincidental to the similarities. If you infringe on your rights, contact me ......

Indicate the source for reprinting.