Zrozumienie nowego podejścia Web API

Question

Zdaję sobie sprawę, że nie każdy korzysta z dokładną architekturę przy opracowywaniu aplikacji MVC, ale załóżmy, że mam następującą strukturę:

App.Core --> Class Library (POCO or Domain objects) 
App.Data --> Class Library (Repository and Entity Framework) 
App.Service --> Class Library (Service layer with all business logic) 
App.Web --> asp.net MVC 3.0 project 

---

App.Data --> Has a reference to App.Core 
App.Service --> Has a reference to App.Core and App.Data 
App.Web --> Has a reference to App.Core and App.Service 

Wewnątrz naszej MVC Aplikacja staramy się postępować zgodnie z tym podejściem:

• Wewnątrz naszego kontrolera (w ramach metody), tworzymy instancję ViewModel.
• Wypełniamy że ViewModel wywołanie metody z naszego App.Service warstwy
• Po ViewModel jest wypełnione, to wracamy do widoku (więc widok jest obecnie silnie wpisany).

Dzieje się to w 99.9% przypadków. Jest czysto, nam się to podoba i bardzo dobrze się prezentuje .. tak!

Teraz moje pytanie jest następujące:

Jeśli zdecydujemy się przenieść naszą aplikację MVC 4.0 i rozpocząć korzystanie z nowego API podejście internetowej , nie jestem pewien, że w pełni zrozumieć, gdzie (lub jak) pasowałoby to do naszej obecnej architektury?

Należy pamiętać, że jesteśmy otwarci na zmianę tej sytuacji!

Czy powinniśmy utworzyć nową warstwę App.WebAPI, która znajduje się pomiędzy App.Service i App.Web? Oznacza to, że wewnątrz naszych kontrolerów nie będziemy już musieli wywoływać App.Service bezpośrednio, ale zamiast tego nową warstwę App.WebAPI?

Lub pozostaw interfejs Web API w warstwie App.Web i spraw, by kontrolery wywoływały inne kontrolery APIController, które z kolei wywoływałyby warstwę App.Service?

Nie jestem pewien, czy mam tu jakiś sens ... ale proszę, zasugeruj cokolwiek, ponieważ jestem ciekawy różnych danych wejściowych.

Dzięki

Answer 1

Istnieje kilka przypadków do rozważenia:

Czy chcesz, aby ten Web API służyć jako warstwa usług i dostępu do danych dla aplikacji MVC? Jeśli, tak, to powinieneś całkowicie usunąć wszystkie odwołania do App.Service z projektu ASP.NET MVC i poprosić o zapytanie do Web API, aby pobrać dane. W tym przypadku interfejs Web API znajduje się pomiędzy aplikacją ASP.NET MVC a dostępem do danych. Jest to Web API, który rozmawia z warstwą usługi i udostępnia ją za pośrednictwem protokołu HTTP.

A może chcesz udostępnić dodatkowe API dla swojej strony internetowej, z którego mogą korzystać inni klienci (poza przeglądarkami internetowymi)? W tym przypadku aplikacja ASP.NET MVC i Web API znajdują się na tej samej warstwie. Obie kwerendy warstwy usługi do wypełnienia modeli widoku, to tylko, że w przypadku aplikacji MVC przekazujesz te modele widoku do widoków, które z kolei przekonwertować je do HTML, podczas gdy w warstwie Web API prawdopodobnie używasz nieco innych modeli widoku, ale które są nadal zapełniane z warstwy usługi i przekazywane do klienta za pomocą odpowiedniego mechanizmu serializacji (JSON, XML, ...)

Answer 2

Wiem, że jest późno, ale szukałem tej samej rady i znalazłem ten post.

Nie ma "zarówno MVC i Web API siedzieć w tej samej warstwie" oznacza więcej prac konserwacyjnych na kod, a może powielanie kodu? czy nie jest to sieć mvc uważana za klienta przeglądarki? dla mnie sensowne jest, aby interfejs WebAPI był Twoją jedyną warstwą dla wszystkich innych, a to z kolei wywoływałoby twoją warstwę usługi do przetwarzania.

Jakie korzyści daje pozostawienie interfejsu API i MVC bezpośrednio do warstwy usługi? Czy web API nie może być opakowaniem wokół warstwy usługi?