LINQ to SQL và Entity Framework có rất nhiều điểm chung, nhưng mỗi cái có những đặc tính riêng nhắm đến những trường hợp khác nhau trong Orcas (bản VS 2008).

LINQ to SQL có các đặc tính hướng đến việc phát triển nhanh ứng dụng với CSDL Microsoft SQL Server. LINQ to SQL cho phép bạn có một cái nhìn chặt chẽ về kiểu với cấu trúc của CSDL của bạn. LINQ to SQL hỗ trợ việc ánh xạ 1-1 trực tiếp cấu trúc dữ liệu của bạn vào các lớp; một bảng đơn có thể được ánh xạ vào một cấu trúc phân cấp (ví dụ một bảng có thể chứa person, customer và employee) và các khóa ngoài có thể ánh xạ thành các quan hệ strongly-typed. Bạn có thể thực hiện truy vấn trên các các bảng, các view hay thậm chí các kết quả dạng bảng trả về bởi một function thông qua các phương thức. Một trong những mục tiêu thiết kế chính của LINQ to SQL là nhằm làm cho nó có thể dùng được ngay đối với những trường hợp thông thường; vậy nên, ví dụ bạn truy cập một tập các order thông qua thuộc tính Orders của một customer, và các order của customer đó chưa được đọc vào, LINQ to SQL sẽ tự động đọc vào từ CSDL cho bạn. LINQ to SQL dựa trên những quy ước cho trước, bạn có thể dựa trên các quy ước này để tùy biến, chẳng hạn như thay đổi các thao tác mặc nhiên cho việc insert, update và delete bằng cách tạo ra những câu lệnh thao tác với CSDL (ví dụ “InsertCustomer”, “UpdateCustomer”, “DeleteCustomer”). Các phương thức này có thể gọi các thủ tục trong CSDL hay thực hiện thêm các thao tác để xử lý các thay đổi.

Entity Framework có các đặc tính nhắm đến các ứng dụng doanh nghiệp (“Enterprise Scenarios”). Trong một doanh nghiệp, một CSDL thông thường được kiểm soát bởi DBA (người quản trị CSDL), cấu trúc của CSDL thông thường được tối ưu cho việc lưu trữ (hiệu năng, tính toàn vẹn, phân hoạch) hơn là cho một mô hình ứng dụng tốt, và có thể thay đổi qua thời gian khi dữ liệu và việc sử dụng phát triển lên. Với ý tưởng này, Entity Framework được thiết kế xung quanh việc xây dựng một mô hình dữ liệu hướng tới ứng dụng, ít phụ thuộc, thậm chí có thể khác một chút so với cấu trúc CSDL thực sự. Ví dụ, bạn có thể ánh xạ một lớp đơn (hay “thực thể”) và nhiều table/view, hay ánh xạ nhiều lớp vào cùng một table/view. Bạn có thể ánh xạ vào một cấu trúc phân cấp vào một table/view đơn (như trong LINQ to SQL) hay vào nhiều table/view (ví dụ: person, customer, employee có thể nằm trong các bảng riêng biệt vì customer và employee chỉ chứa thêm một số thông tin không có trong person, hoặc lặp lại các cột từ bảng person). Bạn có thể nhóm các thuộc tính vào các kiểu phức hợp (“complex”, hay “composite”), ví dụ một kiểu Customer có thể có thuộc tính “Address” với kiểu Address có các thuộc tính Street, City, Region, Country và Postal). Entity Framework cũng cho phép bạn biểu diễn quan hệ nhiều-nhiều một cách trực tiếp, mà không cần tới bảng kết nối như một thực thể trong mô hình dữ liệu, và có một đặc tính mới được gọi là “Defining Query”, có thể được dùng cho việc biểu diễn một bảng ảo với dữ liệu lấy từ một câu truy vấn (ngoài trừ việc cập nhật phải thông qua một stored procedure). Khả năng ánh xạ mềm dẻo này, bao gồm tùy chọn dùng các stored procedure để xử lý các thay đổi, có thể được thực hiện chỉ bằng cách khai báo, hoặc chỉnh sửa lại khi yêu cầu thay đổi, mà không cần phải biên dịch lại ứng dụng.

Entity Framework bao gồm LINQ to Entities đưa ra nhiều tính năng giống với LINQ to SQL trên mô hình ứng dụng ở mức khái niệm; bạn có thể xây dựng các câu truy vấn trong LINQ (hay trong “entity SQL”, một phiên bản mở rộng của SQL để hỗ trợ các khái niệm như strong-typing, đa hình, kiểu phức hợp…) trả về kết quả ở dạng các đối tượng CLR, thực thi các thủ tục hay các hàm trả về kiểu bảng thông qua các phương thức, và cho phép gọi một phương thức để lưu lại các thay đổi.

LINQ to SQL and the Entity Framework have a lot in common, but each have features targeting different scenarios in the Orcas timeframe.

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.

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.

The Entity Framework includes LINQ to Entities which exposes many of the same features as LINQ to SQL over your conceptual application data model; you can build queries in LINQ (or in “Entity SQL”, a canonical version of SQL extended to support concepts like strong typing, polymorphism, relationship navigation and complex types), return results as strongly typed CLR objects, execute stored procedures or table valued functions through strongly-typed methods, and process changes by calling a single save method.

However, the Entity Framework is more than LINQ to Entities; it includes a “storage layer” that lets you use the same conceptual application model through low-level ADO.NET Data Provider interfaces using Entity SQL, and efficiently stream results as possibly hierarchical/polymorphic DataReaders, saving the overhead of materializing objects for read-only scenarios where there is no additional business logic.

The Entity Framework works with Microsoft SQL Server and 3rd party databases through extended ADO.NET Data Providers, providing a common query language against different relational databases through either LINQ to Entities or Entity SQL.

So while there is a lot of overlap, LINQ to SQL is targeted more toward rapidly developing applications against your existing Microsoft SQL Server schema, while the Entity Framework provides object- and storage-layer access to Microsoft SQL Server and 3^rd party databases through a loosely coupled, flexible mapping to existing relational schema.

I know this is a confusing area, and we’re trying to figure out how best to describe these differences to help customers make the appropriate choices.  Please let me know if this helps, or if there are still areas of confusion…

Thanks,

Michael Pizzo

Principal Architect

Microsoft Data Programmability