In which scenarios does ADO. NET Entity Framework work?

In which scenarios does ADO. NET Entity Framework work?
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 OO perspective, how do you run the next code result: 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 the 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-level Get/Set, and access control. 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, if each User has only one boss, use EF or some ORM: var bigBoss = user. superior. superior; if you want to write SQL statements, you may feel a little annoyed. the difference between the amount of code and readability can be seen. 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. You can know that FullName is actually the combination of FirstName and LastName. If you create a Model/Entity, generally: copy the code 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;} copy the Code. In the database, you only need to store FirstName, LastName, and FullName as the calculated value, and the load is delayed. What's more, we can extend from the above example to encapsulate some database operations in Entity: copy the code public partial class User {public User Superior {get; set ;} public User BigBoss {get {return this. superior. superior ;}} copy the Code. At this time, only one Superior relation is stored in the database. BigBoss can be used as the calculation 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 of all, we are criticized for performance issues. We hope that we will not leave the principle behind to talk about EF performance. Due to its running principle, EF's performance loss usually occurs in: the special operations in the Process of cache comparison During the creation and conversion of Expression Tree into SQL are inevitable under unreasonable extreme performance pressure, 2. It can be solved by disabling the comparison or cache. 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. Normally, it is used to traverse and query the data in the entire table, and then filter the data at the OO level without any need to perform instantiation, query, or waste cache resources for comparison, either it is a waste of query resources. 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 is a solution, but it does not seem so perfect. In some non-ORM application systems and centralized SQL management architecture, maintenance may be easier in this scenario.