Czy to jest antipattern do wywoływania usług WEBAPI od kontrolerów MVC?

Question

Jeśli zdecydowano się użyć interfejsu WebAPI do utworzenia warstwy usługi, która będzie używana dla różnych klientów. Jaki byłby najlepszy sposób na zaprojektowanie klienta WWW?

Ponieważ interfejs WebAPI jest przyjazny stronom internetowym, możliwe jest skonsumowanie go bezpośrednio z klienta przy użyciu javascript. Jednak martwiłbym się, że może to dość szybko stać się bałaganiarskim, a javascript nie jest najłatwiejszą technologią do testów jednostkowych.

Alternatywą byłoby użycie klasy HttpClient do wywołania usług REST ze kontrolerów MVC. Czy to jest prawidłowe podejście?

Przypuszczam, że powyższe dwa podejścia można połączyć, ale obawiałbym się, że to się nie uda. Czy zgodziłbyś się, że lepiej wybrać jedno podejście lub drugie?

Przepraszam, że widziałem wiele postów na temat korzystania z WebAPI lub MVC, ale żaden z nich nie łączył tych dwóch.

Myśli?

Answer 1

Alternatywą byłoby użyć klasy httpclient zadzwonić usługi REST od kontrolerów MVC. Czy to jest prawidłowe podejście?

Tak, zdecydowanie. Po prostu ten kod nie powinien być umieszczany w kontrolerach, ale raczej w warstwie DAL, ponieważ kontrolerzy nie powinni wiedzieć, skąd pochodzą dane (płaski plik, baza danych, Web API, ...).

Więc istnieją 2 sposoby:

• zdecydować się zużywać API Web z aplikacji klienckiej MVC z wykorzystaniem protokołu HTTP. W tym przypadku utworzysz implementację dla swojego repozytorium (warstwa DAL), która będzie używać klienta HTTP i bezpośrednio zwróci modele domeny
• Zdecydujesz się bezpośrednio korzystać z usług zawartych w tym interfejsie internetowym bez wysyłania żądań HTTP. W tym przypadku odwołujesz się do zestawu zawierającego warstwę usługi dla twojego Web API w aplikacji klienckiej MVC i bezpośrednio ten zestaw staje się warstwą usługi dla twojej aplikacji MVC. W tym przypadku interfejs Web API za pośrednictwem protokołu HTTP obsługuje innych klientów: javascript, mobile, ...

Wybór podejścia zależy od konkretnego scenariusza i wymagań. Czy potrzebujesz obsługiwać interoperacyjne klienty inne niż aplikacja kliencka MVC? W każdym razie zacznij od zdefiniowania warstwy usługi w oddzielnym zestawie zawierającym modele domen i takie tam. Wtedy zawsze możesz odsłonić tę warstwę usługi za pomocą Web API (lub usługi WCF lub cokolwiek innego) lub bezpośrednio odwoływać się do nich z klientów .NET.

Answer 2

Wydaje mi się, że masz projekt MVC i próbujesz oddzielić operacje API od projektu MVC do osobnego projektu interfejsu API? W takim przypadku musisz zważyć korzyści przed skokiem i stworzyć oddzielny projekt serwisowy.

Po utworzeniu oddzielnego projektu interfejsu API, nie można łatwo korzystać z metod obsługi bezpośrednio z javascript w projekcie MVC z powodu bariery między domenami (oczywiście są JSONP i CORS, ale nie robią rzeczy tak łatwo), więc musisz polegać na klasie HttpClient tworząc zbędne metody pakowania w kontrolerach, aby komunikować się z usługą.

Warto pomyśleć o api w tym samym projekcie MVC, gdy masz widoki, które potrzebują danych dostarczonych przez twoje metody API, ale tylko musisz użyć ApiController zamiast Controller.