LINQ to SQL VS LINQ to Entities
Short Description
· L2S is tightly coupled - object property to specific field of database or more correctly object mapping to a specific database schema
· L2S will only work with SQL Server.
· EF allows mapping a single class to multiple tables
· EF will handle M-M relationships
· EF will have ability to target any ADO.NET data provider
LINQ to SQL
· LINQ to SQL has features targeting "Rapid Development" against a Microsoft SQL Server database.
· Think of LINQ to SQL as allowing you to have a strongly-typed view of your existing database schema. LINQ to SQL supports a direct, 1:1 mapping of your existing database schema to classes; a single table can be mapped to a single inheritance hierarchy (i.e., a table can contain persons, customers, and employees) and foreign keys can be exposed as strongly-typed relationships.
· You can build LINQ queries over tables/views/table valued functions and return results as strongly typed objects, and call stored procedures that return strongly typed results through strongly typed methods.
· A key design principle of LINQ to SQL is that it "just work" for the common cases; so, for example, if you access a collection of orders through the Orders property of a customer, and that customer's orders have not previously been retrieved, LINQ to SQL will automatically get them for you.
· LINQ to SQL relies on convention, for example default insert, update, and delete logic through generated DML can be overwritten by exposing appropriately named methods (for example, "InsertCustomer", "UpdateCustomer", "DeleteCustomer"). These methods may invoke stored procedures or perform other logic in order to process changes.
| I want to | LINQ to SQL is applicable |
| Use an ORM solution and my database is 1:1 with my object model | Yes |
| Use an ORM solution with inheritance hierarchies that are stored in a single table | Yes |
| Use my own plain CLR classes instead of using generated classes or deriving from a base class or implementing an interface | Yes |
| Leverage LINQ as the way I write queries | Yes |
| Use an ORM but I want something that is very performant and where I can optimize performance through stored procedures and compiled queries | Yes |
LINQ to Entities
· The Entity Framework has features targeting "Enterprise Scenarios".
· In an enterprise, the database is typically controlled by a DBA, the schema is generally optimized for storage considerations (performance, consistency, partitioning) rather than exposing a good application model, and may change over time as usage data and usage patterns evolve.
· With this in mind, the Entity Framework is designed around exposing an application-oriented data model that is loosely coupled, and may differ significantly, from your existing database schema.
· For example, you can map a single class (or "entity") to multiple tables/views, or map multiple classes to the same table/view.
· You can map an inheritance hierarchy to a single table/view (as in LINQ to SQL) or to multiple tables/views (for example, persons, customers, and employees could each be separate tables, where customers and employees contain only the additional columns not present in persons, or repeat the columns from the persons table).
· You can group properties into complex (or “composite”) types (for example, a Customer type may have an “Address” property that is an Address type with Street, City, Region, Country and Postal code properties).
· The Entity Framework lets you optionally represent many:many relationships directly, without representing the join table as an entity in your data model, and has a new feature called "Defining Query" that lets you expose any native query against the store as a "table" that can be mapped just as any other table (except that updates must be performed through stored procedures).
· This flexible mapping, including the option to use stored procedures to process changes, is specified declaratively in order to account for the schema of the database evolving over time without having to recompile the application.
| I want to | LINQ to Entities is applicable |
| Write applications that can target different database engines in addition to Microsoft SQL Server | Yes |
| Define domain models for my application and use these as the basis for my persistence layer. | Yes |
| Use an ORM solution where my classes may be 1:1 with the database or may have a very different structure from the database schema | Yes |
| Use an ORM solution with inheritance hierarchies that may have alternative storage schemes (single table for the hierarchy, single table for each class, single table for all data related to specific type) | Yes |
| Leverage LINQ as the way I write queries and have the query work in a database vendor agnostic manner. | Yes |
| Use an ORM but I want something that is very performant and where I can optimize performance through stored procedures and compiled queries | Yes |
0 التعليقات:
إرسال تعليق