Hiện tại có những khác biệt lớn khác giữa Dịch vụ dữ liệu WebApi và WCF mà dường như chưa ai đề cập đến. Tôi ước MS sẽ ra một bài báo hay so sánh hai loại này.
Tôi đã theo dõi OData một thời gian và cả WebApi. Tôi luôn tìm thấy một vài điểm khác biệt chính.
Đầu tiên, tôi không chắc sếp của bạn nói gì khi nói "MS đang ủng hộ WebApi", có nghĩa là họ không ủng hộ OData ?? IMO, họ đang ủng hộ cả hai và hiện tại có một số chồng chéo tối thiểu. Windows Azure Data Market hiển thị Dữ liệu của họ bằng OData, Azure Table Storage sử dụng OData, SharePoint 2010 cho phép Truy vấn OData trên Dữ liệu của nó và các Sản phẩm khác từ MS cũng đang hỗ trợ nó, chẳng hạn như Excel PowerPivot. Đó là một khung truy vấn rất mạnh khi nói đến Dữ liệu quan hệ. Và bởi vì nó RESTful, bất kỳ ngôn ngữ, khuôn khổ, thiết bị nào, v.v. đều có thể tích hợp với nó.
Đây là những gì tôi thích về Dịch vụ dữ liệu OData + WCF:
Dịch vụ Dữ liệu OData + WCF cuối cùng đã cho phép Ứng dụng Khách "biểu đạt" hơn khi truy vấn Dữ liệu qua Web. Trước đây, chúng ta luôn phải sử dụng ASMX hoặc WCF để xây dựng các API Web cứng nhắc, khó sử dụng và yêu cầu thay đổi liên tục bất cứ khi nào giao diện người dùng muốn một thứ gì đó hơi khác. Ứng dụng Máy khách chỉ có thể chỉ định các tham số để chỉ định tiêu chí trả về. Hoặc làm như tôi đã làm và "Tuần tự hóa" Biểu thức LINQ và chuyển chúng dưới dạng Tham số và tái hydrat hóa vào Expressions<Func<T,bool>>trên Máy chủ. Nó khá. Đã hoàn thành công việc, nhưng tôi muốn sử dụng LINQ trên Máy khách và nó đã được dịch qua Web bằng REST, đó là chính xác những gì OData cho phép và tôi không muốn sử dụng giải pháp "hack" của riêng mình.
Nó giống như việc hiển thị "TRANSACT SQL" mà không cần đến Chuỗi kết nối DB. Đơn giản chỉ cần cung cấp một Url và whoala! Bắt đầu truy vấn. Tất nhiên, cả Dịch vụ Dữ liệu WebApi và WCF đều hỗ trợ Xác thực / Cấp quyền, vì vậy bạn có thể kiểm soát quyền truy cập, nối thêm các câu lệnh "Where" dựa trên vai trò hoặc cấu hình dữ liệu khác. Tôi muốn làm điều này trong Lớp Api Web của mình hơn là trong SQL (như xây dựng Chế độ xem hoặc Procs được lưu trữ). Và bây giờ Ứng dụng có thể tự tạo truy vấn, bạn sẽ thấy các công cụ Báo cáo Ad-Hoc và BI bắt đầu tận dụng OData và cho phép Người dùng xác định kết quả của riêng họ. Không dựa vào Báo cáo tĩnh khi chúng có quyền kiểm soát tối thiểu.
Khi phát triển trong Silverlight, Windows 8 Metro hoặc ASP.NET (MVC, WebForms, v.v.), bạn có thể chỉ cần thêm "Tham chiếu Dịch vụ" trong Visual Studio vào Dịch vụ Dữ liệu WCF và nhanh chóng bắt đầu sử dụng LINQ để truy vấn Dữ liệu VÀ bạn nhận được một "Ngữ cảnh dữ liệu" trên Máy khách, có nghĩa là nó theo dõi các thay đổi và cho phép bạn "Gửi" các thay đổi của mình trở lại Máy chủ một cách nguyên tử. Điều này rất giống với Dịch vụ RIA cho Silverlight. Tôi lẽ ra đã sử dụng Dịch vụ dữ liệu WCF thay vì Dịch vụ RIA, nhưng tại thời điểm đó, nó không hỗ trợ DataAnnotations hoặc Actions, nhưng bây giờ thì có :) Dịch vụ dữ liệu WCF có một lợi thế khác so với Dịch vụ RIA, đó là khả năng thực hiện "Phép chiếu" từ Khách hàng. Điều này có thể giúp tăng hiệu suất, trong trường hợp tôi không muốn trả lại tất cả các Thuộc tính từ một Thực thể. Có "Ngữ cảnh dữ liệu"
Vì vậy, WCF Data Services rất tuyệt nếu bạn có Dữ liệu có mối quan hệ, đặc biệt nếu bạn đang sử dụng SQL Server và Entity Framework. Bạn sẽ nhanh chóng có thể hiển thị Dữ liệu có thể truy vấn + Hành động (lệnh gọi để gọi hoạt động, tức là quy trình công việc, quy trình nền) qua REST với rất ít Mã. Dịch vụ dữ liệu WCF vừa được cập nhật. Bản phát hành mới ra mắt. Kiểm tra tất cả các chức năng mới.
Nhược điểm của Dịch vụ dữ liệu WCF là bạn mất "quyền kiểm soát" đối với HTTP Stack. Tôi thấy lỗ hổng lớn nhất là trong IQueryable<T>Phương thức trả về Bộ sưu tập. Không giống như Dịch vụ RIA VÀ WebApi, bạn KHÔNG có toàn quyền truy cập để phát triển logic trong Phương pháp IQueryable. Trong Dịch vụ RIA và WebApi, bạn có thể viết bất kỳ mã nào bạn muốn miễn là bạn quay lại IQueryable<T>. Trong Dịch vụ Dữ liệu WCF, bạn CHỈ có quyền truy cập để thêm Tuyên bố "Ở đâu" bằng các Expression<Func<T,bool>>Phương thức chặn. Tôi thấy điều này thật đáng thất vọng. Ứng dụng hiện tại của chúng tôi sử dụng Dịch vụ RIA và tôi thấy chúng tôi thực sự cần khả năng kiểm soát logic IQueryable. Tôi hy vọng tôi sai về điều này và tôi chỉ thiếu một cái gì đó
Ngoài ra, Dịch vụ Dữ liệu WCF cũng KHÔNG hỗ trợ đầy đủ cho tất cả các Nhà khai thác LINQ. Tuy nhiên, nó vẫn hỗ trợ nhiều hơn WebApi.
Còn WebApi thì sao ???
- Tôi thích quyền kiểm soát đối với Yêu cầu / Phản hồi Http
- Thật dễ dàng để làm theo (tận dụng các mẫu MVC). Tôi chắc rằng sẽ có nhiều công cụ hơn.
Hiện tại (theo sự hiểu biết của tôi), không có hỗ trợ "Ngữ cảnh dữ liệu" trên Máy khách (tức là Silverlight, Mã phía máy chủ ASP.NET, v.v.), vì WebApi không thực sự về Mô hình dữ liệu thực thể như Dịch vụ dữ liệu WCF / OData Là. Nó có thể hiển thị Bộ sưu tập của các đối tượng mô hình bằng cách sử dụng IQueryable / IEnumerable, nhưng không có "Thuộc tính điều hướng" của Khóa chính / Khóa ngoại (tức là customer.Invoices) để sử dụng khi các Đối tượng được tải trên Máy khách, vì không có "Ngữ cảnh dữ liệu" tải chúng không đồng bộ (hoặc trong một lệnh gọi bằng cách sử dụng $ expand) và quản lý các thay đổi. Bạn không có "đại diện" do mã tạo mô hình dữ liệu thực thể của bạn trên Máy khách, giống như bạn làm trong Dịch vụ RIA hoặc Dịch vụ dữ liệu WCF. Tôi không nói rằng bạn không thể / không có Mô hình trong Máy khách đại diện cho Dữ liệu của bạn, nhưng bạn đã điền Dữ liệu theo cách thủ công và quản lý "hóa đơn" nào sẽ được đặt cho từng "khách hàng" sau khi họ được truy xuất qua Web. Điều này có thể trở nên phức tạp, đặc biệt là với tất cả các nội dung Async đang diễn ra. Bạn không biết cuộc gọi nào sẽ quay lại trước. Điều này có thể khó giải thích ở đây, nhưng chỉ cần đọc về nội dung "Ngữ cảnh dữ liệu" trong Dịch vụ RIA hoặcDịch vụ Dữ liệu WCF . Vì vậy, khi giao dịch với Line of Business Apps, đây là vấn đề lớn đối với tôi. Điều này chủ yếu dựa trên năng suất và khả năng bảo trì. Bạn có thể tạo Ứng dụng một cách khó hiểu mà không có Ngữ cảnh dữ liệu. Nó chỉ làm cho mọi thứ dễ dàng hơn, đặc biệt là trong Silverlight, WPF và bây giờ là Windows 8 Metro. Việc có các Thực thể quan hệ được tải vào bộ nhớ một cách không đồng bộ và có Hai ràng buộc thực sự rất hay.
Nói như vậy, điều này có nghĩa là một ngày nào đó WebApi có thể hỗ trợ "Ngữ cảnh dữ liệu" trên Máy khách? Tôi nghĩ nó có thể. Ngoài ra, với nhiều công cụ hơn, Dự án Visual Studio có thể tạo tất cả các Phương thức CRUD của bạn dựa trên Lược đồ cơ sở dữ liệu (hoặc Khung thực thể).
Ngoài ra, tôi biết rằng tôi chỉ đề cập đến .NET đến .NET Frameworks khi nói đến việc làm việc với WCF Data Services hoặc WebApi, nhưng tôi rất biết rằng HTML / JS cũng là một người chơi chính. Tôi chỉ đề cập đến những lợi ích mà tôi đã tìm thấy khi xử lý Silverlight UI hoặc ASP.NET Server-Side Code, v.v. Tôi tin rằng với sự ra đời của "IndexedDB" trong HTML5 / JavaScript sẽ có "Ngữ cảnh dữ liệu" và Khung LINQ trong JavaScript cũng có thể trở nên khả dụng, làm cho khả năng truy vấn Dịch vụ OData từ JavaScript trở nên dễ dàng hơn (bạn có thể sử dụng DataJS ngày nay với OData). Thêm vào đó, việc sử dụng KnockoutJS để hỗ trợ MVVM và Binding trong HTML / JS cũng sẽ giúp nó trở nên dễ dàng :)
Tôi hiện đang nghiên cứu nền tảng nào để sử dụng. Tôi cũng rất vui khi sử dụng, nhưng tôi có xu hướng nghiêng về OData dựa trên thực tế là Ứng dụng tiếp theo của tôi chủ yếu về Analytics (chỉ đọc) và tôi muốn có RESTful Api giàu tính biểu cảm. Tôi tin rằng Dịch vụ Dữ liệu OData + WCF mang lại cho tôi điều đó bởi vì WebApi chỉ hỗ trợ $ take, $ via, $ filter, $ orderby qua Bộ sưu tập. Nó KHÔNG hỗ trợ Phép chiếu, Bao gồm ($ expand), v.v. Tôi không có nhiều "Cập nhật / Xóa / Chèn" và Dữ liệu của chúng tôi khá liên quan.
Tôi hy vọng những người khác sẽ tham gia thảo luận và đưa ra suy nghĩ của họ. Tôi vẫn đang quyết định và rất muốn nghe những ý kiến khác. Tôi thực sự nghĩ rằng cả hai đều là khuôn khổ tuyệt vời. Tôi tự hỏi nếu bạn thậm chí phải chọn, tại sao không sử dụng cả hai nếu cần. Từ Client, tất cả về việc xây dựng các cuộc gọi REST. Chỉ là một suy nghĩ :)