Rules to follow while creating a POCO class in Entity Framework
Four important rules to follow when creating a POCO class in Entity Framework. In the article, POCO vs. Entity classes, we have seen how POCO classes are different from entity classes in their persistence. We already know that these classes are persistent ignorant. To persist, we need to adapt some persistence infrastructure. EF is a common persistent infrastructure and we will use the same. Even though these classes do not inherit from the EntityObject class, EF provides change tracking information and maintains relationships for these classes. We create thios class in a persistent ignorant fashion and make use of EF functionality. You may have a question how is this possible? The answer to this question is using proxies and is discussed in a separate article.
We need to follow certain rules while creating these classes to avail the functionality of EF for persistence. For persistence, EF needs metadata. To provide metadata, we create an Entity Data Model. To understand this concept, let us select only two tables Customer and SalesOrder while creating EDM. The created model contains two entities as shown below.
Note that after we create EDM, we need to do the following. Select .edmx file in the solution explorer and select properties option. In the properties window, for the Custom Tool property, do not set any value. When the setting is done, classes will not be generated.
First, let us look at the rules we need to follow.
Rule 1: We should create these classes exactly like entities in the Model. Which means that the names and types of properties (both scalar properties and navigational) should match with those of the class. The below code represents the Customer and SalesOrder classes.
Rule 2:Navigational properties which return an EntityCollection should be of return type ICollection and marked as virtual to enable lazy loading.
Rule 3: Every property should be declared with virtual keyword in c# and with Overridable keyword in vb. When we use the property as virtual, EF creates a dynamic proxy class at runtime. This proxy class gives the functionality such as change notification, relationship fixup and Lazy loading to the POCO class. Because of the proxy classes created at runtime, these entities can be persisted back to the database successfully. This persistence process is similar to the class inherited from the EntityObject class.
Note: if we do not want change tracking with proxies, we declare only navigational properties as virtual to get lazy loading proxies. Declare all other scalar properties without a virtual keyword. We can also implement change tracking by using snapshot change tracking mechanism. I suggest not to use change tracking proxies because these proxies create problems while serializing the objects in enterprise applications.
Rule 4:Should be instantiated using ObjectContext.CreateObject method. We need to use the CreateObject method, and only then proxy object is created. The following code defines a Customer class which is created manually. This code example is created adhering to the first three rules. We will see the fourth rule when we create a proxy object. The article How to create Change tracking proxies demonstrates how to create a proxy object using CreateObject method.
We need to follow certain rules while creating these classes to avail the functionality of EF for persistence. For persistence, EF needs metadata. To provide metadata, we create an Entity Data Model. To understand this concept, let us select only two tables Customer and SalesOrder while creating EDM. The created model contains two entities as shown below.
Note that after we create EDM, we need to do the following. Select .edmx file in the solution explorer and select properties option. In the properties window, for the Custom Tool property, do not set any value. When the setting is done, classes will not be generated.
First, let us look at the rules we need to follow.
Rule 1: We should create these classes exactly like entities in the Model. Which means that the names and types of properties (both scalar properties and navigational) should match with those of the class. The below code represents the Customer and SalesOrder classes.
Rule 2:Navigational properties which return an EntityCollection should be of return type ICollection and marked as virtual to enable lazy loading.
Rule 3: Every property should be declared with virtual keyword in c# and with Overridable keyword in vb. When we use the property as virtual, EF creates a dynamic proxy class at runtime. This proxy class gives the functionality such as change notification, relationship fixup and Lazy loading to the POCO class. Because of the proxy classes created at runtime, these entities can be persisted back to the database successfully. This persistence process is similar to the class inherited from the EntityObject class.
Note: if we do not want change tracking with proxies, we declare only navigational properties as virtual to get lazy loading proxies. Declare all other scalar properties without a virtual keyword. We can also implement change tracking by using snapshot change tracking mechanism. I suggest not to use change tracking proxies because these proxies create problems while serializing the objects in enterprise applications.
Rule 4:Should be instantiated using ObjectContext.CreateObject method. We need to use the CreateObject method, and only then proxy object is created. The following code defines a Customer class which is created manually. This code example is created adhering to the first three rules. We will see the fourth rule when we create a proxy object. The article How to create Change tracking proxies demonstrates how to create a proxy object using CreateObject method.