Chcę napisać nowy interfejs API stylu REST i spojrzałem na ServiceStack i całkiem mi się podoba. Widziałem jednak, że Microsoft wydał projekt ASP.Net Web API jako część nowej wersji MVC 4 beta. Czy ktoś spojrzał na nowy projekt Web API? Czy możesz podać jakieś zalety / wady każdego systemu?
Odpowiedzi:
Mają bardzo podobne przypadki użycia, ponieważ jako główny opiekun projektu ServiceStack mam dobry wgląd w zalety ServiceStack i wiele naturalnych korzyści jego projektu opartego na komunikatach .
ServiceStack istnieje od 2008 r. Jako projekt prowadzony przez OSS od samego początku, którego jednym celem jest promowanie prawidłowego projektowania i wdrażania zdalnych usług wolnych od tarcia.
W pogoni za najwyższą prostotą zbudowano go wokół prostego i eleganckiego rdzenia - z większością funkcji naturalnie wiążących się z modelami , a nie z kontrolerami - co właśnie robi MVC, WebApi (a także każdy inny program Web Service Framework produkowany przez Microsoft ).
Przyjęcie projektu opartego na wiadomościach oferuje lepsze podejście do usług zdalnych, ponieważ promują one bardziej rozszerzalne i mniej kruche usługi, upraszczają wzorce dostępu i połączeń oraz zawierają wiele innych naturalnych korzyści, które otrzymujesz za darmo .
Jako podstawowa misja, walczymy ze złożonością na każdym etapie, dążąc do utrzymania niewidocznego i nieinwazyjnego API oraz unikania wprowadzania jakichkolwiek nowych koncepcji lub sztucznych konstrukcji, które nie są jeszcze znane twórcom platformy .NET lub serwisów internetowych.
Na przykład IService<T>implementacja usługi jest tylko standardową klasą C # z zależnościami okablowanymi automatycznie. Cienkie i lekkie opakowania są używane w celu zapewnienia spójnego i zunifikowanego API wokół głównych typów IHttpRequest i IHttpResponse w czasie wykonywania . Umożliwiają również dostęp do bazowych klas Request and Response ASP.NET lub HttpListener, dzięki czemu nigdy nie jesteś ograniczony podczas korzystania z ServiceStack.
Oto krótki przegląd kontrastowych stylów API promowanych przez ServiceStack i WCF . WebApi różni się od WCF tym, że zachęca do projektowania API REST-full. Jeśli chodzi o przykłady między 2, jest to jedyny znany przykład, który mam z tą samą usługą napisaną zarówno w ServiceStack, jak i WebApi .
ServiceStack koncentruje się przede wszystkim na prostocie, wydajności i promowaniu najlepszych praktyk w zakresie usług internetowych / zdalnych, koncentrując się wokół obejmujących wzorce projektowania usług zdalnych Martina Fowlersa w możliwie idiomatycznym języku C #:
Fasada Wzór - co sugeruje użycie batchful, interfejsy gruboziarnistych gdy kiedykolwiek komunikować poprzez granice procesowych.
Wzór DTO ( MSDN ) - Nagrania użycie Poços celowych do generowania formatu drutu swoich odpowiedziach usług internetowych.
Brama Wzór ( MSDN ) do hermetyzacji Twojego klienta i serwera komunikacji między modelami Client Bramka / dto i szczeblami interfejs usługi.
Te wzory zapewniają czyste rozdzielenie problemów i beztarciowe iteracyjne doświadczenie twórców.
Usługa sieci Web ServiceStack w jej rdzeniu koncentruje się wokół niezależnego i automatycznie okablowanego IService<T>interfejsu czystego języka C # , który daje całkowitą swobodę w definiowaniu umowy o usługę internetową z własnymi DTO żądania i odpowiedzi przy użyciu czystych POCO - dzięki czemu interfejs API usługi ServiceStack jest praktycznie niewidoczny i nie jest -inwazyjne, tzn. wyodrębnienie logiki usług C # i uruchomienie jej poza hostem ServiceStack jest banalne.
Ta lista jest dobrym przykładem tego, co otrzymujesz za pomocą tylko 1 klasy C # .cs w ServiceStack :
Klasy RestServiceBase i ServiceBase są przeznaczone do hostowania niestandardowej logiki C # w celu maksymalnego potencjalnego ponownego wykorzystania, jak to możliwe, np. Jego pierwszy projekt w DTO pozwala na odroczone i proxy wykonanie, w którym ta sama usługa C # może być również hostowana i wykonywana na hoście MQ czyli to, co się dzieje po zarejestrowaniu IMessageServicejak gospodarz RedisMQ i wywołać usługę za pośrednictwem /asynconewaypunktu końcowego (czyli client.SendOneWay()C # Klientów)
Można również łatwo delegować i tworzyć usługi złożone przy użyciu base.ResolveService<T>()metody, która zwraca automatycznie okablowane wystąpienie wybranej usługi, jak pokazano w przykładzie usługi Nortwind CustomerDetails :
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
W większości przypadków ServiceStack serializuje większość obiektów C # zgodnie z oczekiwaniami - oto lista możliwych typów zwrotów ( z tej odpowiedzi ):
Następujące typy nie są konwertowane i są zapisywane bezpośrednio do strumienia odpowiedzi:
Przykład obsługi niestandardowych nagłówków HTTP można zobaczyć w tym przykładzie CORS, w którym można skonfigurować nagłówki HTTP globalnie lub dla poszczególnych usług.
Istnieje wiele opcji zwracania HTML w ServiceStack, które szczegółowo wyjaśniono tutaj .
Elastyczne i szybkie serializers mają podstawowe znaczenie w API, aby zapewnić szybki czas reakcji i versionable API, które nie łamie istniejących klientów, dlatego ServiceStack obejmuje najszybsze serializers tekstowe dla .NET z opcją Nuget umożliwienia @marcgravell „s protokół Bufory (najszybszy serializator binarny .NET).
Serializatory tekstu ServiceStack są bardzo odporne i potrafią wytrzymać ekstremalne wersje bez błędów.
Zdecydowana natura ServiceStack pozwala na szybki, typowy, zwięzły interfejs API usług internetowych typu end-to-end z wbudowaną obsługą klientów Sync / Async C # / .NET i Async Silverlight bez żadnego kodu:
var response = client.Send<HelloResponse>(new Hello { Name = "World!" });
client.SendAsync<HelloResponse>(new Hello { Name = "World!" },
r => Console.WriteLine(r.Result), (r, ex) => { throw ex; });
Ponieważ zwraca tylko czysty JSON, jest także trywialnie wykorzystywany przez innych klientów HTTP, np. Przykład klienta JS używającego jQuery :
$.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
alert(todos.length == 1);
});
Wszystkie usługi C # / .NET ServiceClient mają te same interfejsy, dzięki czemu są wysoce testowalne i można je zamieniać do tego stopnia, że ten sam test jednostkowy służy również jako test integracji XML, JSON, JSV, SOAP .
W swojej misji zapewnienia bezproblemowego i czystego działania deweloperów, ServiceStack obejmuje również wbudowaną weryfikację typów i obsługę błędów, w której zgłoszenie wyjątku C # lub użycie jego wbudowanej płynnej weryfikacji zapewnia klientom uporządkowane, wpisane błędy łatwo dostępne na klientach usług WWW , np .:
try {
var client = new JsonServiceClient(BaseUri);
var response = client.Send<UserResponse>(new User());
} catch (WebServiceException webEx) {
/*
webEx.StatusCode = 400
webEx.ErrorCode = ArgumentNullException
webEx.Message = Value cannot be null. Parameter name: Name
webEx.StackTrace = (your Server Exception StackTrace - if DebugMode is enabled)
webEx.ResponseDto = (your populated Response DTO)
webEx.ResponseStatus = (your populated Response Status DTO)
webEx.GetFieldErrors() = (individual errors for each field if any)
*/
}
Aby korzystanie z błędów w JavaScript było banalne, możesz użyć lekkiej biblioteki JavaScript ss-validation.js, aby w prosty sposób powiązać błędy odpowiedzi z polami formularza HTML za pomocą jednego wiersza kodu. Przykład projekt SocialBootstrapApi zapewnia dobrą prezentację tego produktu.
W ServiceStack MVC PowerPack re-write i poprawki Dużo dolega ASP.NET i MVC z zamienników dla jego kalectwo sesji i buforowania XML obciążone dostawców ASP.NET z własnym czyste i wolne od uzależnień realizacji ICacheClient i ISession API.
ServiceStack obejmuje również nowszy i czystszy model dostawcy uwierzytelniania i autoryzacji z wbudowaną liczbą różnych AuthProvider:
Moduł Uwierzytelniania jest całkowicie opcjonalny i jest oparty na czystych interfejsach API ICacheClient / ISession i OrmLite, co pozwala na przechowywanie Sesji w pamięci, Redis lub Memcached, a dane UserAuth są przechowywane w RDBMS SQLServer, MySql, PostgreSQL, Sqlite obsługiwanych przez OrmLite a także magazyn danych Redis lub InMemory (przydatne do tworzenia / testowania).
ServiceStack jest bardzo dobrze udokumentowany, gdzie większość informacji o frameworku znajduje się na wiki GitHub . Dokumentację dla innych części frameworka (np. Serializery, Redis, OrmLite) można znaleźć na stronie servicestack.net/docs/
Projekt ServiceStack.Examples zapewnia kod źródłowy dla wszystkich wersji demonstracyjnych i szablonów startowych ServiceStack, podczas gdy projekt SocialBoostsrapApi stanowi świetny punkt wyjścia do opracowania aplikacji jednostronicowej Backbone.js z ServiceStack i MVC opartej na szablonie Twitters Bootstrap.
Oprócz tego grupa informacji Google zawiera skarbnicę informacji, która w ostatnich latach znacznie się rozwinęła.
ServiceStack to platforma .NET 3.5, która działa na hostach ASP.NET i HttpListener i może być hostowana na platformie .NET lub Mono (ciekawostki: www.servicestack.net jest obsługiwany przez CentOS / Mono). Dzięki temu usługi sieciowe ServiceStack mogą być hostowane na:
ServiceStack mocno wierzy w model rozwoju Open Source, w którym jest aktywnie rozwijany w środowisku otwartym i od samego początku był hostowany na licencji liberalnej OSS (Nowa BSD). Na dzień dzisiejszy otrzymał wkład od ponad 47 programistów i obecnie zajmuje 3. najczęściej oglądany projekt C # na GitHub .
Uważam, że największa wada jest taka sama dla większości innych projektów OSS .NET, w których nie została opracowana (lub nawet wymieniona jako dostępna opcja) przez Microsoft. Oznacza to, że rzadko jest to pierwszy wybór przy ocenie frameworka. Większość użytkowników adoptuje ServiceStack tylko w ostateczności, gdzie albo są sfrustrowani narzuconym tarciem i kruchością WCF, albo wydajnością preferowanego stosu Microsoft.
ServiceStack został bardzo dobrze przyjęty z pozytywną opinią większości ludzi, którzy ocenili to jako widoczne pozytywne opinie w grupie mailingowej . Od tego roku konto na Twitterze @ServiceStack śledzi wzmianki i opinie w swoich ulubionych .
The wspólnotowych zasobów wiki strona to miejsce dobre, aby dowiedzieć się więcej o ServiceStack na dziko z linkami do blogi, pod odlewy, prezentacje, GIST i więcej.
Jest nowa główna różnica, którą należy uwzględnić - ServiceStack nie jest już darmowy od wersji 4. Ponieważ na SS-pro jest dość jednoznaczna odpowiedź, chciałem rzucić kilka na Web API
Pro's:
Cons :
Korzyści dodatkowe
(Zachęcamy do pozostawienia komentarzy poniżej, wyjaśniających, dlaczego Web API ma zalety lub zalety / wady, które mogę dodać)
Naprawdę nie mogę powiedzieć wiele o ServiceStack, ale Web API ma wiele świetnych funkcji i jest obecnie w wersji 2.
Niektóre rzeczy, które możesz zrobić za pomocą interfejsu API sieci Web:
asynci await.Jako klient ServiceStack tutaj najważniejszy jest dla mnie ServiceStack.
https://github.com/ServiceStack/Issues/issues/606
Więc. Znaleziono błąd, zidentyfikowano błąd, naprawiono błąd. Ten sam dzień. Nadzwyczajne wsparcie!
Minął rok, kiedy używam SS i to wszystko świetnie. ORMLite to czysta magia. Udało mi się zmienić mapowanie okropnej bazy danych MySQL do integracji z aplikacjami mobilnymi. Brak zmian w bazie danych, ponieważ jest ona używana z zapleczem php z innymi aplikacjami ...
Mythz jest przykładem dotyczącym wsparcia i wyjaśnień. Podniosło to moją wiedzę na temat projektowania aplikacji i prostoty obsługi. Spróbuj, a zrozumiesz.
Nie porównuj też SS z WebAPI. To nie wystarczy, SS przynosi znacznie więcej do Twojego zestawu narzędzi. ServiceStack.Text to także świetny Automapper.