Entity Framework 4 in action Reading Notes -- Chapter 1: Data Access overload: Entity Framework (3)

In the previous article, we saw the difference between the relationship world and the object world. As you can see, the applicationProgramProcessing database data using object models is complex. The next question is who will handle this complexity. The answer is that if you are crazy, you can solve it by yourself. Otherwise, you can use the O/RM tool, or more specifically, the Entity Framework.

What is o/RM?

O/RM is the abbreviation of Object/relational ing. It uses metadata information to interact with the database. In this way, your data layerCodeYou do not need to know the database structure. The core of O/RM is ing. The ing technology binds the relational world and the model world together. Through ing, you can express how a class and its attributes are associated with one or more tables in the database. It uses the O/RM tool engine to dynamically construct SQL statements, retrieve data, and convert data to objects. Similarly, you can use ing data to update back to the database by tracking the changes in object attributes. The ing information is usually displayed in an XML file.

O/RM is a complex software that frees developers from the burden of management and database interaction. It handles collisions between objects and the relational world, query data and convert it to an object. Track object updates to reflect changes in the database. When you have a tool that can help you do it, it is silly to manually encode the implementation function.

There are many O/RM products on the market and free commercial products. So far, nhib.pdf has the strongest and most stable functions. However, its leadership is gradually threatened by the New Entity Framework.

How does Entity Framework access data?

Entity Framework is a complex software. Its overall structure consists of components, each of which implements specific functions. Shows its main components:

The Entity Data Model)

The Entity Data Model is the bond between the model and the database. Here, you describe the structure of databases and models and how to map them. The greatness of the object data model is that it separates your applications from the underlying storage. Databases and models can have completely different structures, but they are always associated by the Entity Data Model.

The Object Data Model consists of three XML files, each of which has a specific task. The ing files of these object data are summarized as follows:

(1). Conceptual Model

A conceptual model describes a model class. This file is divided into two parts: the first part contains all the entities and relations, and the second part contains a detailed description of their structure. An important feature of this file is that it can be divided into many files. This feature is useful when your model grows larger and the performance of the Visual Studio designer gets lower and lower.

(2). Storage Model

A storage model is equivalent to a conceptual model, but it describes the organization of a database. This file is not only conceptually similar to the previous one, but also uses the same XML node. Unlike the conceptual model, the storage model cannot be divided into multiple physical files. The first part of this file lists all tables, views, stored procedures, and affected foreign keys. The second part describes the items listed in the first node,

(3). ing model

The ing file is completely different. It does not describe anything, but makes up for the shortcomings of the previous two models. What's amazing about ing: ing a class to one or more tables, ing a table to one or more classes, defining inheritance ing, and retrieving ing stored procedures for updates and objects. This file contains only one important node, which is associated with classes and tables and can be repeated multiple times to ensure that a class can be mapped to multiple tables, and vice versa. Like a stored file, this file cannot be divided into multiple files.

Object services)

The object service layer Manages objects in the object framework. The Entity Framework mainly deals with the mismatch between databases and objects, so it requires a lot of tasks for objects. When a query is executed, the object service layer converts it into a command tree and passes it to the underlying entity client. This process is slightly different, depending on the query technology you choose. If you use LINQ to entities, LINQ provider generates an expression tree, which is parsed and converted in the command tree. If Entity SQL is used, the object service parses the string and generates another command tree. This process is called query conversion.

When the database query has been executed and the data is restructured through ing at the bottom layer, the object service is responsible for creating objects using the input structure. The input data is organized into rows and columns in the form of a conceptual model rather than a database. This means that each row represents an object. If it has an attribute that references other classes, This column contains all rows of that class. Indicates how the data is organized:

Because of this data organization method, the process of creating an object is quite simple. We call this process "Object concrete ".

When the object is ready for use, context comes in handy. Context refers to the lifecycle of communication between an application and an object framework. The context is created using a well-known class (possibly objectcontext or context class), which can be referenced in the code or never released. The context class is used from the very beginning because it creates the entry to the query object model.

The object is automatically added to the context after it is materialized, but this row may be ignored due to performance reasons. During the specific process, if an object already exists in the context, the engine skips the object referenced in the context and returns it to the code that is executing the query. That is to say, the context plays a local cache role.

Objects automatically appended to the context are tracked by the Status management component. This mechanism ensures that any modification to the object can be managed and recorded in the database correctly. To achieve this, state management stores the initial data of each object during loading for comparison and optimization updates. The status management component has many options to customize its behavior.

Finally, the object service layer coordinates data storage updates and queries status manager modifications. It also controls the creation of Pipeline Code required to execute commands.

Entity client data provider)

The physical client is responsible for communicating with the database. to simplify its architecture, this layer does not physically connect to the database, but relies on the ADO. NET data provider. Since the Object Service uses the EDM object model to manage objects, the entity client uses all EDM files. It needs to map and store the file conversion command tree of the model to the SQL command of the execution database, and then convert the data of the table structure to the conceptual data of the conceptual model.

At this point, you must clearly understand how the system processes queries, use them to access the database, and convert the result data into objects. In special cases where the maximum performance is required, you may ignore the service object Layer to directly query this layer. The performance improvement not only skips one layer, but also avoids the slowest concrete process of query execution. Obviously, LINQ to entities does not apply to directly querying the entity client, because the object to be operated by LINQ is completely unknown at this layer. In this case, Entity SQL is the only language that can directly query the real client.

LINQ to entities

LINQ to entities is a specialized language of LINQ. You can query models by type. Thanks to the LINQ syntax, you can perform type queries on the model and return an object that is checked during compilation.

Although the LINQ to entities operation object, it is finally translated into an SQL statement. Many LINQ methods or overloading cannot be expressed in SQL. For example, the elementat method is not supported but is effective in syntax. The call to this method will not cause compilation errors, but the notsupportedexception exception will be thrown during runtime. The second parameter of the where method overload accepts an integer and cannot be translated into an SQL statement, which only causes a runtime exception.

Entity SQL

Entity SQL is another way to query object models. Like LINQ to entities, Entity SQL queries the model. The difference is that Entity SQL is string-based and is more desirable in some cases.

Entity SQL makes one of the most complex languages we have ever seen. When the Entity Framework team created a query language for the Entity Framework, they chose a syntax similar to SQL, which is also called Entity SQL. With the development and evolution of Entity SQL, more and more features are added. The range of the query function becomes wider and new language functions are required. Currently, Entity SQL has more than 150 functions and is compatible with the original SQL syntax.

Despite its complexity, Entity SQL is superior to INQ to entities in some cases. First, it is string-based and can easily create queries based on conditions during runtime. Second, Entity SQL is the only language that can be used for data retrieval at the underlying layer (directly using the entity client.

Written at the end

Finally, I have finished writing the first chapter. There are too many theories. The next chapter will truly enter the world of Entity Framework.