Why the properties and methods in the NHibernate must be virtual

If you have ever used NHibernate 2.0 or higher, you must have encountered the following error: NHibernate.InvalidProxyTypeException:The Following types May is used as proxies:
NHibernateExamples.Entities.OrderLine:method get_unitprice should be ' public/protected virtual ' or ' protected internal Virtual
NHibernateExamples.Entities.OrderLine:method set_unitprice should be ' public/protected virtual ' or ' protected internal Virtual

Gee, we forgot to mark the UnitPrice attribute in the Orderline entity as virtual, and it's strange why it had to be set to virtual at first, which is a constant doubt about the first contact with NHibernate.

The simplest answer to this question is this: because we need to set the member to virtual, it is to implement our lazy load magic function.

But the more detailed answer is more interesting, we know that any real ORM must have an important function is lazy loading, if you get an object through ORM, you do not want it to automatically get the entire object graph of all the data (not by default), And you don't want to add some messy code to check whether a particular relationship has been loaded, and we need to load them only when we need them. This should be the ORM's responsibility. Ideally, you can access these properties, and if the data is not yet loaded, the ORM will be responsible for loading the data that is currently needed when you first visit.

Nhiernate has this capability, but it does not require you to inherit a base class from nhibernate or implement some interfaces. That's weird? How did the NHibernate do it? In fact, when a delay load is required, at run time, NHibernate is using the proxy of your class. What about the agent? A nhibernate proxy is a type that nhibernate dynamically generated when your program initializes nhibernate (occurs when the application first starts and occurs only once). If you do not show the entity specified to you that does not require lazy loading, then NHibernate will generate a proxy for each entity you have, and the type of each entity agent is actually inherited from this entity. This way you can do some interception when you are working with this type.

You can now safely use the order instance, you can even access an instance of the employee and the customer, and nothing will happen and there will be no query operation. However, note that when you go to a non-identifier member (that is, properties and methods) of the proxy instance, nhibernate to make sure that the non-identifier member you requested has data, it goes to the database to request data . In this case, when you visit the properties and methods of the employee and customer, NHibernate will go to the database to request the data you want. So how did that nhibernate come to this mechanism? Because the agent overrides the properties and methods of your entity classes (entities), when the properties and methods are called, NHibernate checks that if the data for the current instance already exists, it will only invoke the implementation of the properties and methods in the entity class, if there is no data, It will first fetch the data and then invoke the implementation of the properties and methods in the entity class.

This is the basic idea of a face object, and your entity class is the base class of the NHibernate proxy. These proxies will add some extra behavior to the behavior of your entity classes (entities). NHibernate needs to rewrite all public members to ensure that these extra behaviors can be triggered at the right time.