In which scenarios does ADO. NET Entity Framework work ?, Ado. netentity

In which scenarios does ADO. NET Entity Framework work ?, Ado. netentity

After zhihu answered the question, he turned back.

 

Enity Framework is already the main ORM in. NET. From the beginning of a Mapping concept, ORM has been sublimated to a certain extent, especially EF and other improvements to the object-oriented capabilities of the ORM framework. To put it bluntly, the orm enables the database to be better encapsulated and abstracted throughout the application process.

In the beginning, ORM is only Mapping. The most basic thing is the correspondence between tables and classes, Column and attribute, which is only the most basic. At this level, database objects are encapsulated into business objects at the object-oriented language level through Mapping, that is, the business layer. Then, database objects can be operated as business objects.

However, for a long time, the elevation of ORM was plagued by the "impedance mismatch" between objects and relationships. For a long time, the level of many ORM is only maintained in the way of CRUD using objects. In addition to reducing code errors and improving the development efficiency of simple queries, the results of complex queries, performance, and so on must be returned to the underlying operating framework, such as ADO, across layers.. NET or even stored procedures to solve the problem.

Therefore, EF and other ORM in simple query scenarios are competent in application scenarios.


From the perspective of application scenarios, this is also obvious in B/S and C/S. What is the biggest difference between Web users and desktop software? -- WYSIWYG. After you have been operating on the web page for a long time, you will not be able to close the page. You must submit the page and obtain the next page to update the data status and UI. on the desktop, your operations, such as drawing, the results came out immediately after the operation. Of course, the Web 2.0 technology is solving this problem.

This is also the problem in OO and RDBMS.

From the perspective of OO, how does the result of running the next code:

user.Name = "Indream Luo";

In OO, the Name attribute of the user object is updated. If it is a desktop software, the user name should be changed.

However, if the data of this object exists in a relational database or any database, the results will not escape this routine:

var object = db.Get(id);change(ref object);db.Update();

You need to Push the update in the past to persist operations and data.

At the beginning of storage layering, pushing updates is inevitable. Even in the aspect-based applications, object updates are pushed to the UI. The role that ORM plays when standing in an inconsistent application scenario is a lubricant role.

What I can think of right away is the cache mechanism of EF and nhib.pdf. EF is a level-1 cache, while NH is a level-2 Cache. If it is manual, EF can also be level-2. Next, in. NET, the most important thing is to have LINQ. In the case of a proper Provider, you can convert the serialization operation of OO to the serialization operation of the target. Here, the serialization operation of LINQ to SQL is used, this saves the trouble of splicing SQL statements and SQL injection. In addition, the latency loading feature of LINQ greatly reduces the workload of user control over SQL Execution.

On the basis of operation synchronization, there is also the structure synchronization problem. Table Structure and object structure synchronization are a major task of Using ORM. EF has the default generation tool, and DB First, Model First, and Code First modes are available. With the automatic generation of synchronization SQL, the selection is now the widest, and NH also has some corresponding generators, in terms of database priority, the drag-and-drop operations by the younger brother, LINQ to SQL, are the most amazing.

In this scenario, along with the use of related tools, EF and other ORM are suitable for sequential operations, reducing the workload of database operation management and structure synchronization, and reducing development costs.


Finally, the impedance mismatch problem is unavoidable.
The object relational model and the relational database model were largely inconsistent in the past. What ORM needs to do now is to make the two closer, so that the features on one side can be more smoothly reflected on the other side.

I wrote a summary in the last few months about some of the methods used by EF in the latest project-Entity Framework and object-oriented. If it is too long, select the focus.

EF covers: type matching, object structure, and data source differentiation.

In terms of type matching, the OO type and the database type are matched, which is the basis of the ORM. For integers, floating points, strings, and dates in basic types, EF may be characterized by Enum, Complex Type, and geographic location, the implementation method is also ideal.

The object structure is the most amazing thing about EF. EF's Model, that is, Entity, can be used to implement the integration relationship. It can also be synchronized to the table structure through the external key control in EF, which achieves excellent Implementation of the reference and dependency relationship; supports virtual classes,Object-levelGet/Set and access control are all very useful.

By using Model First, I found that the database design is closer to the paradigm. I can design a table structure more reasonably because of the convenience brought by the LINQ and object structures ". For example, if you want to obtain the boss of a user, assuming that each User has only one boss, you can use EF or some ORM:

var bigBoss = user.Superior.Superior;

If you want to write SQL statements, you may feel a little annoyed. You can see the difference between the amount of code and readability.

Finally, data sources are differentiated. One problem is that the data of an object does not necessarily come from a database or a database. I often use this example.
For example, a User has three fields: FirstName, LastName, and FullName. We can know that FullName is actually the combination of FirstName and LastName. If you create a Model/Entity, generally:

public partial class User{    public string FirstName { get; set; }    public string LastName { get; set; }    public string FullName    {        get        {            if (fullName == null)            {                this.fullName = String.Format("{0} {1}", this.FirstName, this.LastName);            }            return this.fullName;        }    } string fullName;}

In the database, you only need to store FirstName, LastName, and FullName as the calculated value, and the loading is delayed.

What's more, we can extend from the above example to encapsulate some database operations in Entity:

public partial class User{    public User Superior { get; set; }    public User BigBoss    {        get        {            return this.Superior.Superior;        }    }}

In this case, only one Superior relation can be stored in the database, and BigBoss can be used as the computing value. Of course, you are happy to cache and delay loading, but EF has already processed the cache.

In extreme cases, it is indeed possible to "play" a lot of Object-Oriented Design Patterns in Table relationships.

In conclusion, EF is applicable to scenarios with high priority of object-oriented structures and features.


In contrast, we also talk about unsuitable scenarios.

First, we are criticized for performance issues,In this case, we do not want to talk about EF performance based on principles..

Due to its running principle, EF's performance loss usually occurs in:

1 is inevitable, 2 can be solved by disabling the comparison or cache, and 3, 4, and 5 are the main problems.
For example, recursion is used to obtain an index chain in a tree structure. If it is done through OO, it is either to make a round-trip to the database many times, or to traverse the object table at least once, or to add some special "ugly" index fields.
The maximum performance pressure is extended when the previous problem is involved. For example, the special operations performed in the SQL Server Stored Procedure are the fastest, and the pure OO method is certainly not reached.
These two special items are the best solution to solve through a more native database. You can mix it with EF or use it independently, but don't think that a silver bullet can solve all problems at the same time. EF provides SQL Execution Methods.
Performance leaks are not a proprietary term and are temporarily used by me. This is because of unnecessary performance waste caused by EF. In particular, due to the delayed loading feature of LINQ, many developers who are not clear about the features of LINQ can easily instantiate the LINQ sequence without any need, wasting system resources. Usually:

• Traverse and query the full table data, and then filter the data at the OO level.
• It is unnecessary to execute instantiation and query, or waste resources for cache comparison or query.

I can only say that this is a level problem for developers, although it is difficult to locate the problem, especially in general, it will cause memory leakage.

The most common problem is back to Data Model synchronization. When the data model is changed, it needs to be synchronized. If business data already exists, it is troublesome. I have never used EF's Migration. It's a solution,It seemsNot so perfect. In this scenario, in the centralized SQL management architecture of some non-ORM application systems,PossibleIt is easier to maintain.

How to Use ADONET Entity Framework

4.1
Www.microsoft.com/..d4248363
 
How does ADONET Entity Framework view T?

The SQL Profile tool that comes with SQL Server. Check the toolbar of SQL Server.
If you want to write in. net
Public string toSql ()
{
Using (var db = new SqlEntities ()){
Var Q = db. SQL. Select (cc => cc. id );
Return (ObjectQuery) Q). ToTraceString ();
}
}