Myślę, że dyskusja na temat programowego wykorzystania usług zorientowanych na usługi a interakcja ludzi jest jasna.
Ale jeśli miałbym stworzyć aplikację, która wykorzystuje zarówno programowy interfejs API, jak i stronę internetową, która korzysta z danych połączonych przez ten sam interfejs API, czy skłania się ku korzystaniu tylko z ASP.NET?
Jak łatwo jest zintegrować ASP.NET i WCF do pracy z tą samą aplikacją?
Jeśli chodzi o pisanie jednej aplikacji, która wykorzystuje zarówno ASP.NET/MVC, jak i WCF, nie jest to świetne. Interfejs WebAPI mógł poprawić, ale w jednym projekcie, który znam z użyciem WCF i MVC w tej samej aplikacji, ostatecznie utrzymano dwa różne zestawy modeli reprezentujące te same pojęcia - jeden dla kodu WCF i jeden dla MVC kod. Możesz sobie wyobrazić wszystkich twórców map, którzy musieli pisać, aby tłumaczyć rzeczy między dwoma modelami - było tam wiele wierszy kodu, których można było / należy unikać.
Częściowo dzieje się tak dlatego, że obiekty żądania i odpowiedzi WCF powinny być opatrzone adnotacjami [DataContract], a ich właściwości - [DataMember], podczas gdy MVC tego nie wymaga. Z drugiej strony, Idiomatic MVC będzie chciał mieć ViewModels, które mają inne cele niż WCF DataContracts. Oczywiście możliwe jest, że użycie dwóch pełnych zestawów obiektów domeny miało więcej wspólnego z prawem Conwaya niż konflikt WCF i MVC, ale warto zauważyć, że WCF i MVC mają różne cele i wymagania w zakresie wyników i danych wejściowych.
Osobiście jestem zwolennikiem opracowania prostego, ale potężnego interfejsu API zaplecza zorientowanego na usługi, szczególnie gdy potrzebujesz wielu klientów. Myślę, że pojawienie się doskonałych frameworków JavaScript MVVM i micro-MVC sprawia, że jest to naturalny wybór, ponieważ pisanie kodu aplikacji przy użyciu BackboneJS , KnockoutJS i innych pozwala na stworzenie wydajnego środowiska programistycznego. Następnie możesz wykorzystać zaplecze w wybranym przez siebie mikro MVC do zbudowania aplikacji internetowej lub na kliencie mobilnym, a Twoi partnerzy mogą również zdalnie korzystać z tego samego interfejsu API.
Sugestia
Zarówno interfejs WebAPI, jak i stos usług mogą być dobrymi kandydatami do budowania interfejsu API zaplecza. Polecam Service Stack, ponieważ używam go od kilku miesięcy i okazało się, że jest doskonałym zamiennikiem WCF. Obecnie piszę serię samouczków na temat stosu usług na moim blogu .
Grupa utrzymująca stos usług opublikowała przykładową aplikację używającą frameworka do opracowania klonowania StackOverflow, który pokazuje wzorzec programistyczny, który moim zdaniem jest szczególnie atrakcyjny. Wiąże się z prostym zapleczem usług opartych na modelach, które można sobie wyobrazić, że są konsumowane przez witrynę internetową MVC, aplikację mobilną lub cokolwiek innego. Cele projektowe ServiceStack wyraźnie zachęcają do wzorca, który powinien prowadzić do mniejszego powiązania klienta z serwerem. Chodzi o to, aby unikać rozmownych interfejsów API z rozmowami, na przykład GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)na rzecz mniejszej liczby metod. Możesz zaimplementować to samo w stosie usług, jak to:
[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();
}
}
Korzyść, do moich oczach, jest to, że zamiast posiadania rozprzestrzeniania logiki biznesowej wychodzi na wiele, wiele odrębnych metod GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm),GetCustomers() , to wszystko w jednym miejscu. Powinno to prowadzić do łatwiejszego do utrzymania kodu.
Przypadkowo, Stack Exchange zatrudnił oryginalnego autora Service Stack . Nadal aktywnie angażuje się w projekt usługi stosu.
Szczególnie lubię kolejki komunikatów dla niektórych rzeczy - i chociaż WCF na to pozwala, WebAPI nie. ServiceStack pozwala na wywoływanie tej samej usługi internetowej za pośrednictwem MQ. Więcej informacji na ten temat można znaleźć na hoście Redis MQ pod adresem: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis
@tzerb odpowiedział poprawnie na IMO, ale chciałem przedłużyć tę odpowiedź. Interfejs API sieci Web ASP.NET, który jest obecnie w fazie beta, a projekt OSS to najbliższa platforma, której szukasz.
Krótki opis produktu jest następujący (cytowany ze strony ASP.NET Web API ):
Jeśli chodzi o aplikację kliencką, której możesz używać do korzystania z internetowego interfejsu API, z pewnością nie musi to być aplikacja ASP.NET. Możesz korzystać z interfejsu API ze statyczną stroną HTML za pomocą JavaScript. Możesz to łatwo zrobić za pomocą przydatnych bibliotek JavaScript, takich jak jQuery.
Z drugiej strony możesz z pewnością korzystać z interfejsu API na stronie serwera w dowolnej aplikacji ASP.NET. W projekcie Web API wprowadzono także nowy interfejs API klienta HTTP .NET o nazwie HttpClient, który ułatwia korzystanie z usług HTTP.
Ogólnie rzecz biorąc, oto dobry zestaw zasobów, które możesz zacząć:
Rozpoczęcie pracy z ASP.NET Web API - tutoriale, filmy, próbki
Pamiętaj, że projekt jest wciąż w fazie beta. Polecam śledzenie bloga Henrika F. Nielsena, gdzie zamieszcza on informacje o najnowszych niepublikowanych aktualizacjach projektu. Możesz dotrzeć do kodu źródłowego projektu i przepływu programowania w projekcie ASP.NET Web Stack .
źródło
Myślę, że obecną zasadą jest użycie MVC Web API zamiast WCF do REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx
Model programistyczny jest dość blisko i omijasz czasami nieprzyjemną konfigurację WCF.
źródło