Entityframework metadata design analysis

Since EF codefirst ctp4 has been used before, it is supported in the OEA framework on the third day of ef4.1 release. In addition, we are going to gradually replace the existing large-scale ORM framework and use the metadata system in EF to completely act as the ORM metadata in OEA, so that you can use the ing information to perform more operations. Since we have no time to take down the entire EF msdn, we only read some relatedArticle. Recently, the metadata subsystem of the OEA framework is being reconstructed. Therefore, in this article, I mainly perform a simple analysis on the metadata of EF.

Note: The following analysis only represents my personal opinion.

 

If you do not know ef metadata, I will provide a query article that I think is well written :《. net-ADO. NET Entity Framework: querying metadata. If you are interested, see. This time, I will first give a Quality Analysis of EF, which is convenient for later viewing. The following article will provide a more detailed analysis:

Scalability:★★★★★
Performance:★★
API usability:★★★

 

 

Basic Concepts

 

The entire EF ing information is divided into five categories: object model, conceptual model, storage model, object-to-conceptual model, and conceptual-to-storage model. The first three types indicate static structure information, and the last two types indicate ing information between static structures. All these five types of metadata are described by a flexible metadata system.

Object Model indicates the object model. The metadata describes the features of the object during runtime, such as the class name and attribute name during CLR runtime.

Conceptual Model indicates the logical model, which is related to the database metadata andProgramIt is used to describe the logical "Domain Model" or "business model ".

Storage Model indicates static information in the database, such as the table name and column name.

These three types of models have many commonalities. For example, a unified concept can be used to describe different concepts in different models: the object type is used to describe the class in the object, the table in the database, and the domain entity in the conceptual model. The attribute is used to describe the attributes of the class, the fields of the table, and the attributes of the object. Therefore, EF uses a simple entitytype to describe object types and edmproperty to describe object attributes.

However, there must be differences between them. This means that different attributes must be supported for the same entitytype.

 

 

Property Extension

To address the above problems, EF provides a scalable attribute design:

As the base class of all metadata types, metadataitem provides a property extension system similar to dynamicobject in the form of a set. Each child metadata type is defined/added to a supported attribute metadataproperty through the metadataproperties set. The class declares the following:

For example, the uraltype medium-strong type attribute members is a set of members,

The running time is shown as follows:

When you continue debugging to the base class, you will find that one of the metadataproperties attribute sets in metadataitem is named members, and the value is exactly the set of the five members just now:

Therefore, we can boldly guess that in structualtype, the internal implementation of the members attribute is to register a new metadataproperty item in the collection of the base class.

It can be seen that this is a dynamic property registration mechanism. dynamicobject, WPF, and dependencyproperty in the Dynamic Language Runtime all have similar design ideas in it.

This mechanism allows us to constantly expand attributes. We can control attributes in a non-reflection manner without converting them into child classes; in exchange, the performance of the property system is relatively low.

 

 

Type Extension

The second major extension point is that the metadata type is extensible.

In the previous article, we can see that the system has provided many default metadata types, all of which are in the system. data. metadata. in the EDM namespace, for example, some important types are given:

Of course, this is not all metadata types. In the previous section, metadataitem has a builtintypekind attribute. Its type is an enumeration. It lists all currently supported metadata types in EF, different child meta data types override this attribute to return different values. This design is verySimilar to the expression design in the LINQ SystemAll of them enumerate all subclasses in the top-level base class to facilitate identification of runtime types through enumeration judgment. But they are different: expression indicatesProgramming LanguageBut these expressions are fixed, and we won't be able to expand them. However, the meta data in EF can be expanded at will, which can be seen from the name of the builtintypekind attribute, it indicates the "built-in system type". Of course, you can also see from the attribute propertykind enumeration in metadataproperty that it has two values:

Extended indicates that this attribute is "non-built-in.

With this design, theoretically, we can extend the metadata type of EF in any DLL. You can add all instances to the metadataitem collection.

However, this also bringsDisadvantageFor example, when performing a query, you cannot perform a forced navigation like an ordinary API. In other words, I get a collection of metadataitem. If I don't convert them to subtypes,You cannot use strong-type properties, but you can only use string matching.. Therefore, to query EF metadata with a strong type, you must first understand the structure of the entire metadata, and then use the oftype <t> method in LINQ to query the metadata. For example, I used oftype <edmproperty> to query the attribute list of all members of a given type. This also results in poor performance.

 

 

Why is this design?

As a framework, it is inevitable to design the scalability of the framework, and this is often very important. And I think that in EF's design,Scalability is the primary design goal of the metadata module..

This flexibility requires a rogue: EF, as a general ORM framework, must not only describe the object model, conceptual model, and storage model at the same time, but also take into account the compatibility of various databases, it is also necessary to ensure that all possible databases, methods, and storage structures in the future can be supported and described by the metadata system.

Such a structure,You can design any information of the corresponding type and put it into the metadata system.. Here, why can we say anything, because the design itself can be said to be equivalent to the XML format. Currently, XML, as a common data format, can basically describe all the data. (Why is it equivalent to the XML format? We will not expand it here .)

 

End

Scalability is very important for the framework. Such a metadata system design is very attractive to me. I have considered whether to design the OEA metadata system into a similar structure. However, this is still not done in the end. The reason is that,During system/framework/architecture design, various quality attributes need to be weighed. We should not blindly pursue a certain attribute, but find a proper design.. This is an old saying, but it is often difficult to do it.

Program Design is an art, while trade-offs are the art to be played all the time.