Tôi nghĩ rằng các cuộc thảo luận cho việc sử dụng dịch vụ theo chương trình và tương tác của con người là rõ ràng.
Nhưng nếu tôi tạo một ứng dụng sử dụng cả API lập trình và trang web sử dụng dữ liệu được kết nối bởi cùng một API, liệu nó có thiên về việc chỉ sử dụng ASP.NET không?
Làm thế nào dễ dàng để tích hợp ASP.NET và WCF để làm việc trên cùng một ứng dụng?
Câu trả lời:
Theo như viết một ứng dụng tận dụng cả ASP.NET/MVC và WCF, thì nó không tuyệt vời. WebAPI có thể đã cải thiện vấn đề, nhưng trong một dự án tôi quen với việc sử dụng WCF và MVC trong cùng một ứng dụng, cuối cùng họ đã duy trì hai bộ mô hình khác nhau để thể hiện cùng một khái niệm - một cho mã WCF và một cho MVC mã. Bạn có thể tưởng tượng tất cả những người lập bản đồ họ phải viết để dịch những thứ giữa hai mô hình - có rất nhiều dòng mã có thể có / nên tránh.
Một phần lý do tại sao điều này xảy ra là các đối tượng yêu cầu và phản hồi WCF nên được chú thích bằng [DataContract] và các thuộc tính của chúng với [DataMember], trong khi MVC không yêu cầu điều này. Mặt khác, MVC thành ngữ sẽ muốn ViewModels, có các mục tiêu khác với WCF DataContuces. Tất nhiên, có thể việc sử dụng hai bộ đối tượng miền đầy đủ có liên quan đến luật của Conway so với xung đột WCF & MVC, nhưng đáng để chỉ ra rằng WCF và MVC có các mục tiêu và yêu cầu khác nhau về đầu ra và đầu vào.
Cá nhân, tôi là một phần để phát triển API back end dịch vụ đơn giản nhưng mạnh mẽ, đặc biệt khi bạn có thể muốn nhiều khách hàng. Tôi nghĩ rằng sự ra đời của các khung JavaScript MVVM và micro-MVC tuyệt vời làm cho điều này trở thành một lựa chọn tự nhiên, vì viết mã ứng dụng bằng BackboneJS , KnockoutJS và các khung khác cho phép môi trường phát triển có khả năng. Sau đó, bạn có thể sử dụng phần cuối trong micro MVC mà bạn chọn để xây dựng ứng dụng web hoặc trên máy khách di động và các đối tác của bạn cũng có thể sử dụng cùng một API từ xa.
Gợi ý
WebAPI hoặc Service Stack có thể là ứng cử viên tốt để xây dựng API back end của bạn. Tôi khuyên dùng Service Stack, vì tôi đã sử dụng nó trong vài tháng qua và nhận thấy đây là một sự thay thế tuyệt vời cho WCF. Tôi hiện đang viết một loạt bài hướng dẫn về ngăn xếp dịch vụ trên blog của mình .
Nhóm dịch vụ duy trì nhóm đã đăng một ứng dụng ví dụ bằng cách sử dụng khung để phát triển StackOverflow giống như bản sao, cho thấy một mô hình phát triển mà tôi tin là đặc biệt hấp dẫn. Nó liên quan đến một dịch vụ dựa trên mô hình đơn giản, dựa trên mô hình mà bạn có thể tưởng tượng được sử dụng bởi một trang web MVC, một ứng dụng di động hoặc bất cứ thứ gì khác một cách dễ dàng. Các mục tiêu thiết kế của ServiceStack rõ ràng khuyến khích một mô hình sẽ dẫn đến ít khớp nối hơn giữa máy khách và máy chủ. Ý tưởng là để tránh các API trò chuyện với các cuộc gọi như GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)ủng hộ ít phương thức hơn. Bạn có thể thực hiện điều tương tự trong ngăn xếp dịch vụ như thế này:
[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers
{
public int? RegionId { get; set; }
public string SearchTerm { get; set; }
}
public class CustomersService : Service
{
public object Get(Customers request) {
// handle request
return new CustomersResponse();
}
}
Lợi ích, để đôi mắt của tôi, đó là thay vì có lây lan logic kinh doanh của bạn ra hơn rất nhiều và rất nhiều các phương pháp riêng biệt GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm), GetCustomers(), đó là tất cả ở một nơi. Điều này sẽ dẫn đến mã duy trì nhiều hơn.
Thật trùng hợp, Stack Exchange đã thuê tác giả Service Stack ban đầu . Anh tiếp tục cam kết tích cực với dự án Service Stack.
Tôi đặc biệt thích hàng đợi tin nhắn cho một số thứ nhất định - và trong khi WCF cho phép điều này, WebAPI thì không. ServiceStack cho phép cùng một dịch vụ web được gọi thông qua MQ. Để biết thêm thông tin về điều này, hãy xem Redis MQ Host tại: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@tzerb đã trả lời đúng IMO nhưng tôi muốn mở rộng câu trả lời đó. ASP.NET Web API hiện đang trong giai đoạn thử nghiệm và một dự án OSS là khung công tác gần nhất mà bạn đang tìm kiếm.
Mô tả ngắn về sản phẩm như sau (trích dẫn từ trang ASP.NET Web API ):
ASP.NET Web API là một khung giúp dễ dàng xây dựng các dịch vụ HTTP tiếp cận nhiều khách hàng, bao gồm cả trình duyệt và thiết bị di động. ASP.NET Web API là một nền tảng lý tưởng để xây dựng các ứng dụng RESTful trên .NET Framework.
Đối với ứng dụng khách mà bạn có thể đang sử dụng để sử dụng API web của mình, chắc chắn đó không phải là một ứng dụng ASP.NET. Bạn có thể sử dụng API của mình với trang HTML tĩnh bằng cách sử dụng JavaScript. Bạn có thể thực hiện việc này dễ dàng với một số thư viện JavaScript hữu ích như jQuery.
Mặt khác, bạn chắc chắn có thể sử dụng API của mình trên trang web máy chủ trong bất kỳ ứng dụng ASP.NET nào. Dự án API Web cũng đã giới thiệu API máy khách HTTP .NET mới có tên là httpClient, giúp dễ dàng sử dụng các dịch vụ HTTP.
Nói chung, đây là bộ tài nguyên tốt để bạn bắt đầu:
Bắt đầu với ASP.NET Web API - Hướng dẫn, Video, Mẫu
Hãy nhớ rằng dự án vẫn đang trong giai đoạn thử nghiệm. Tôi khuyên bạn nên theo dõi blog Henrik F Nielsen nơi anh ấy đăng thông tin về các bản cập nhật mới nhất chưa được phát hành cho dự án. Bạn có thể tiếp cận mã nguồn của dự án và luồng phát triển bên trong dự án ASP.NET Web Stack .
Tôi nghĩ rằng hướng dẫn hiện tại là sử dụng API Web MVC thay vì WCF cho REST. http://stephenwalther.com/blog/archive/2012/03/05/int sinhtion-to-the-asp-net-web-api.aspx
Mô hình phát triển khá gần và bạn bỏ qua cấu hình đôi khi khó chịu của WCF.