Introduction to delayed loading in C # (3) -- restore the business rules of the Model)

Ah ~~ Recently, I spent my spare time modifying my blog. I found many foreign spam ads on the message board of my website during this time, so I made a "ip blacklist" function, verification codes are also added for messages and comments. By the way, the background code is sorted out. I hope the newly added verification codes will not cause inconvenience to comments and comments!

In the previous article, we talked about declaring the property to be delayed loaded in the object class as virtual, and then inheriting the object class as a subclass to implement this property in the subclass, works with delegates to achieve perfect latency loading (the original "model layer" is still kept at the bottom layer for the layer-3 structure, at the same time, you can access the "data access layer" higher than others in the attributes of the object class). At the end of the article, there is still a cup of cake because this attribute may be required by our business before the model attribute is delayed, it is not just used as a storage and read function, but contains this complicated or simple logic code in its get or set accessors.

For example, consider this scenario. We have an entity class called a task list, which has two attributes: "Task Name" and "release time ", there are business rules that the task name can be blank, however, if the task name is blank, We need to read the "release time" to generate a task name to replace this null value (for example, "issue20110120191345"). Of course, this example is somewhat far-fetched, the main reason is that I can't think of a very specific instance, but in actual development, this is certainly the case, and the logic code in it may be complicated to your imagination.

Following the examples in the previous two articles, I simulated this phenomenon and made some modifications to the "article" object class, adding a string attribute named getcategoryrecord, basically, it can be seen from the literal that it is called "The get accessor call record of the category attribute ". Therefore, the "article" Class (base class) is modified as follows:

C # code?

12345678910111213141516171819202122232425262728293031

namespace Model{    // Article entity class    public class Article    {        public int ArticleID { get; set; }        public string Title { get; set; }        public string Cotnent{ get; set; }        public DateTime CreateTime { get; set; }        public int CategoryID { get; set; }        /// <summary>        /// Category        /// </summary>        protected Model.ArticleCategory _category;        /// <summary>        /// Category        /// </summary>        public virtual Model.ArticleCategory Category        {            get            {                GetCategoryRecord += "Get category ;";                return _category;            }        }        /// <summary>        /// Get accessors call record of the category attribute        /// </summary>        public string GetCategoryRecord { get; set; }    }}

Here we are concerned about the twoWrite annotation attributesAndProtected field _ category(This is especially important and serves as a link to sub-classes ). Now we can see that there is such a business rule: if the category attribute is get once, point records will be made to the getcategoryrecord attribute. So when designing the code, we immediately thought that if the base class inheriting the model. Article class needs to override this attributeKeep this business unchangedOtherwise, some previously designed business logic will be lost after implementation of delayed loading. Modify its subclass as follows:

C # code?

12345678910111213141516171819202122232425262728293031323334

namespace DModel{    /// <summary>    /// Document    /// </summary>    public class Article : Model.Article    {        /// <summary>        /// Category        /// </summary>        public override Model.ArticleCategory Category        {            get            {                if (base._category == null)                {                    if (CategoryLazyLoader != null)                    {                        base._category = CategoryLazyLoader(CategoryID);                    }                    else                    {                        base._category = null;                    }                }                return base.Category;            }        }        /// <summary>        /// Document classification delayed loader (delegated)        /// </summary>        public Func<int, Model.ArticleCategory> CategoryLazyLoader { get; set; }    }}

Here we can see that base. _ cateogry is the protected field of the base class in the category attribute of the dmodel. Article class, and the base class category is returned. Rough seems a bit messy, but the logic is as follows: the category attribute of the base class returns the value of the _ Category field, that is, the data is stored in the _ Category field rather than in the attribute, but how does the _ Category field have a value? That is, it is obtained by calling the delegate in the subclass. Instead of directly returning this attribute in the subclass, it calls the base class to return the value, in this way, when the get accessor of the category attribute of the subclass is called,First, assign values to the _ categoty field of the base class., And thenSome logic code is executed by calling the category attribute of the base class.Finally, successfullyReturn the _ categoty field of the (already assigned) base class.. All of this is in front of us.Implemented on the basis of delayed Loading. The words are as follows:Sub-classes are responsible for delayed loading, and the base class values are stored and returned!Haha, do you think it is very simple? ^

Here we can see that base. _ cateogry is the protected field of the base class in the category attribute of the dmodel. Article class, and the base class category is returned. Rough looks a little messy, but the logic is as follows: the category attribute of the base class returns the value of the _ Category field, that is, the data exists in the _ Category field rather than in the attribute, but how does the _ Category field have a value? That is, the value is obtained by calling the delegate in the subclass. Instead of directly returning this attribute in the subclass, the base class is called to return the value, in this way, when the get accessor of the category attribute of the subclass is called, The _ categoty field is assigned a value first, and then the category attribute of the base class is called to implement some logic code, finally, the (assigned) _ categoty field is successfully returned. All of this is done on the basis of our previous implementation of delayed loading. Haha, do you think it is very simple? ^

Here we can see that base. _ cateogry is the protected field of the base class in the category attribute of the dmodel. Article class, and the base class category is returned. Rough looks a little messy, but the logic is as follows: the category attribute of the base class returns the value of the _ Category field, that is, the data exists in the _ Category field rather than in the attribute, but how does the _ Category field have a value? That is, the value is obtained by calling the delegate in the subclass. Instead of directly returning this attribute in the subclass, the base class is called to return the value, in this way, when the get accessor of the category attribute of the subclass is called, The _ categoty field is assigned a value first, and then the category attribute of the base class is called to implement some logic code, finally, the (assigned) _ categoty field is successfully returned. All of this is done on the basis of our previous implementation of delayed loading. Haha, do you think it is very simple? ^

In fact, this article is not about the technology of delayed loading. During our development, we often encounter such entity class attributes that implement business code, A model with this property is usually called a blood-filling model ", if the attributes of the model are simple get and set, it is usually called the "anemia model" (of course there may be other names ~). This article does not have any content. It is a supplement to the first two articles. I hope you have not wasted your time.