What scenarios are the ADO-net Entity Framework used in?

After knowing the answer, he turned back.

The enity framework is already the main ORM in. Net. The ORM begins with a mapping concept, and has now been sublimated to the object-oriented capabilities of the ORM framework, especially EF. Effectively, it is the ORM that makes the database more encapsulated and abstracted throughout the application process.

ORM begins with mapping, and the most basic is the correspondence of the table to the class, the column and the attribute, which is just the basis. At this level, database objects are encapsulated as business objects through mapping at the object-oriented language level, that is, the business plane, and then allow operations on the database in a way that operates the business object.

However, for a long time, ORM's ascension has been plagued by the "impedance mismatch" between the object and the relationship. A lot of the level of ORM has been maintained in the way of the object of Crud only, in addition to reduce code errors, improve the development of simple queries, in the complex query, performance, and so on some aspects of the results are to go back to the underlying operational framework such as ADO, or even stored procedures to solve the problem.

So, the scenario where simple queries are applied to the scenario EF and other ORM are capable.


From the application scenario, this point in B/S and C/s will also be very obvious. What is the difference between a user's use of the web and the maximum experience of using desktop software? -What you see is what you gain. You have been working on the web for a long time, a close is all gone, you must submit and then get the next page to update the data status and UI, but also on the desktop, your actions such as drawing, in the operation of the instant results come out. Of course, Web 2.0 technology is a solution to this problem.

The same problem in Oo and RDBMS is also here.

From an OO perspective, you run the next piece of code to see how the result:

" Indream Luo ";

In Oo, the Name property of the user object is updated. If it is a desktop software, then the user's name should also be changed.

But if the object's data is in a relational database, or any database, then the result will not escape this routine:

var Object = db. Get (ID); Change (refObject);d B. Update ();

You need to push the update to the past and persist the operation and data.

At the beginning of the storage hierarchy, push updates are unavoidable, even in the face application, where updates to the object are pushed to the UI. The role of ORM standing in the middle of inconsistent application scenarios is the role of a lubricant.

The feature that I can immediately recall is the caching mechanism of EF and nhibernate. EF is a first-level cache, NH is a level two cache, and if you do it manually it seems that EF can do level two. And then in. The most important point under Net is LINQ. LINQ can translate OO serialization operations into target serialization operations with the right provider, and here is LINQ to SQL, which eliminates the hassle of splicing SQL, SQL injection, and so on. In addition, the features of LINQ lazy loading greatly reduce the user's control over the work of SQL execution.

On the basis of operation synchronization, there is also the problem of structure synchronization. Table structure and object structure synchronization is a great work of using ORM. EF has the default build tool, DB first, model first, Code first three modes to provide choices, plus automatic generation of synchronous SQL, the selectivity is now the most extensive, NH also has some corresponding generators, database priority of the Little Brother LINQ to SQL is the most amazing drag.

in this scenario, with the use of related tools, ORM such as EF is suitable for sequencing operations, reducing database operations management and fabric synchronization effort, and reducing development costs.


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

I wrote a summary in the early months about some of the methods used by the recent project EF-Entity Framework and object oriented. Too long to choose the key to explain.

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

The type matching aspect, is the OO type and the database type to match, this is the ORM Foundation. Integer, floating point, string, date in the underlying type these are just some of the things that EF is more likely to have is the enumeration type (enum), the complex type (Complex type), and the geo-location feature, which is also ideal for implementation.

The object structure aspect is the most amazing place that EF makes me. The model of EF, that is, the entity can realize the integration relationship, it can also be synchronized in the table structure, EF through the foreign Key control, the reference and dependency on the implementation is very good; Support Virtual class,Object-LevelGet/set, access control are very useful.

By using model first, I found that the design of the database was closer to the paradigm. Because of the convenience of LINQ and object structure, I can design the table structure to be more "reasonable". For example, if you want to get the boss of the user's boss, assuming that each user has only one boss, then using EF or some ORM is:

var bigboss = user. Superior.superior;

If you want to write SQL, feel a bit annoying, calculate the amount of code and readability can see the difference.

Finally, the data source is differentiated. One problem is that an object whose data does not necessarily originate entirely from a database, or a database, is an example I often use.
For example, user has three fields: FirstName, LastName, FullName. Can know FullName is actually FirstName and LastName splicing, if Create model/entity, General:

 Public Partial classuser{ Public stringFirstName {Get;Set; }  Public stringLastName {Get;Set; }  Public stringFullName {Get        {            if(FullName = =NULL)            {                 This. FullName = String.Format ("{0} {1}", This. FirstName, This.            LastName); }            return  This. FullName; }    } stringFullName;}

In the database, you only need to store FirstName and Lastname,fullname as the computed value, and it is deferred loading.

What's more, we can also extend from the example above 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 relationship is stored in the database, Bigboss as the calculated value. Of course, you'll be happy to cache and delay loading, but EF has already processed the cache.

In extreme cases, it is true that many object-oriented design patterns can be "played" in table relationships.

Finally, EF is suitable for scenarios where object-oriented structures and features have high precedence.


So relatively, also talk about the non-applicable scene.

First of all, we are criticized for performance issues, which I hope not to put aside the principle of EF performance .

EF because of its execution principle, the performance loss generally occurs in:

1. LINQ is the process of creating and converting expression tree into SQL
2. The process of cache alignment
3. Unreasonable implementation of special operation
4. The problem under the extreme performance pressure
5. Performance leaks

1 is unavoidable, 2 can be solved by closing the pair or the cache, 3, 4, and 5 are the main problems.
Special operations unreasonable for example, recursive, get an index chain of a tree structure. If you do it through OO, you either have to go back and forth many times in the database, or at least iterate through the object table, or add some special "ugly" index fields.
The extreme performance pressure is extended in the case of a previous problem, such as SQL Server's stored procedure execution is the fastest, and the pure OO approach must not be achieved.
These two special items are the best solution through a more native database approach. You can mix with EF, or you can use it alone, but don't be paranoid about having a silver bullet to solve all the problems at once. EF provides a way to execute SQL.
Performance leaks are not a proper noun, it's my temporary use. This means that the EF is causing unnecessary performance waste. In particular, the Lazy loading feature of LINQ, many developers who do not know the LINQ features are prone to instantiate LINQ sequences unnecessarily, wasting system resources. It will usually be:

• Traverse query full table data, then filter at OO level
• Needlessly perform instantiation, query, or waste cache resources, or waste query resources

I can only say that this is a developer level issue, although it is difficult to locate after a problem, especially in general, will cause memory leaks.

Finally, the most common is back to the data model synchronization problem. When the data model changes, it needs to be synchronized, and if there is already business data, it's a hassle. EF's migration I didn't use it, it was a solution but it didn't seem so perfect. In some non-ORM application systems, the SQL Centralized management architecture, in this scenario, may be easier to maintain.

What scenarios are the ADO-net Entity Framework used in?