Shulou(Shulou.com)06/02 Report--

This article will explain in detail what are the three forms of ADO.NET Entity Framework inheritance. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Inheritance is widely used in all kinds of programming, but ADO.NET Entity Framework inheritance still has a certain degree of deficiency, mapping errors are likely to occur, and the MSL part of EDMX must be maintained manually.

ADO.NET Entity Framework inheritance (hereinafter referred to as ADO.NET EF) has a very trusted runtime. The reason why it is afraid to be widely used in projects is because of its poor design. What's wrong with the design of this DSL? First, you can only design the database first and then the entity model; second, if you modify the database structure, and then update the entity model, all your changes will be invalidated, worst of all, there may be mapping errors, and you have to maintain the MSL part of the EDMX manually. Usually, changes to the database structure can be your nightmare.

It is also important to point out that there is a problem with the documents that ADO.NET Entity Framework inherits in MSDN. If you don't believe me, look what I found: MSDN, how could Microsoft do this?

Admittedly, the runtime of ADO.NET Entity Framework inheritance handles inheritance relationships very comfortably. This article takes you to experience the inheritance of ADO.NET EF.

As with the usual inheritance relationship mapping, three ways are supported:

◆ one system, one table mode

◆ type one table mode

◆ one specific class one table mode

I have great disdain for the third way and the third way. I have an article about my opinion: talk about inheritance mapping in detail.

* there is an article about the specific operation method: Single Table Inheritance in Entity Framework. What's wrong with this approach? The "Type" field is acceptable because it is completely transparent at run time; but the "Salary", "Rate" and "Hours" can be empty, which we cannot accept, because it means that, for example, we store a SalariedExployee entity that can openly not assign a value to the Salary, resulting in a business error. This is the "empty redundancy" that I resent. However, there are exceptions to everything, if the properties in the derived class happen to be empty, then the empty will not be redundant, and the benefits of simple and efficient inheritance of a single table can be accepted.

The third way is unacceptable to me, because it will not solve the problem of "relationship sharing" that I have mentioned many times.

Fortunately, ADO.NET EF provides a second way to support *. There is an article about this way:

Entity Framework Modeling: Entity Splitting

Entity Framework Modeling: Entity Splitting Part II

However, I did not set up successfully in the way suggested in this article. Maybe my environment is different. Importantly, I learned a few points about setting inheritance: *, don't manually modify BaseType to set inheritance, but use the "add" → "inheritance" way in the context menu. We then believe that, in addition to BaseType, ADO.NET EF's DSL adds something to the MSL part of EDMX. Second, manually delete the key field properties in the derived class. Third, pay attention to the order of operation.

Now let's use an example to illustrate. This example is used to solve the problem of permissions. The business system judges permissions only on the basis of whether it has some "authority" or not. This authority is represented in the Privilege table as a string. This authority can only be granted to roles. Both users and user groups can belong to a role, and users in a user group can inherit all roles from that user group. The actual application may do some more articles on the authority, such as adding the authority scope object. This has nothing to do with this topic, so it is omitted.

The following figure shows the design of the database:

Create a class library project in Visual Studio 2008. Add an entity data model called "InheritanceDemoModel.edmx" and generate it from the established database, and name the entity connection setting "DemoEntities". As a result, we get this initial result:

First delete the relationship between UserOrGroup and User, then delete the relationship between UserOrGroup and Group, and then change the names of all entity sets to plural.

Now add two inheritance relationships: one is based on UserOrGroup and derived from Group, and the other is based on UserOrGroup and derived by User. And then it goes like this:

Next, change the "abstract" attribute of UserOrGroup to "true", and then delete the UserId attribute of User and the GroupId attribute of Group. After you delete these two properties, map the original two fields (Column) to the Id field of UserOrGroup:

* one step, due to the deletion of the UserId attribute of User and the GroupId attribute of Group, the mapping between the Users attribute of Group and the Groups attribute of User is broken and needs to be remapped:

Save and complete the mapping. Next you can do several tests, for example, the test creates several Privilege, Role, Group, User, and then uses a simple Linq expression to get all the authority of a User.

On the three forms of ADO.NET Entity Framework inheritance what are shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.