Overkill WebApi i kontrolera

Question

Zaczynam integrować WebApi & OData w aplikację testową. Zachowajmy prostotę i trzymajmy się jednego podmiotu domeny - klienta. Oczywiście będę miał kontroler MVC. Wyszukiwanie otrzymuje własny model widoku (oparty na indeksie Lucene), więc będzie to osobny kontroler, teraz ODataController. Ale ponieważ strony do przeglądania/edycji będą miały własne modele widoków, będą one własnymi kontrolerami. Zaczyna się to wydawać przesadą.

Próba znalezienia dobrego projektu, który sprawi, że to zadziała i nadal będzie działał z ideą adresu URL reprezentującego encję. Czy encja w adresie URL powinna być Klientem i jakoś udostępniam różne reprezentacje na podstawie parametrów URL? Czy klient/CustomerSearch/CustomerEdit może być innym podmiotem (co nie brzmi dobrze)?

Answer 1

Przypuszczam, że ta aplikacja WebAPI będzie osobnym rozwiązaniem z rozwiązania ASP.NET MVC, które zamierzasz zbudować. W skrócie, WebAPI będzie warstwą biznesową/domenową, a MVC będzie warstwą prezentacji.

Tak więc, mówiąc o rozwiązaniu WebAPI, potrzebujesz tylko jednego ApiController dla przykładu klienta, który przedstawiłeś powyżej. Żądanie wyświetlenia/zmiany może mieć własne modele widoku ... lub nie. W zależności od tego, jak tworzysz model widoku, możesz mieć jeden model widoku dla klientów lub możesz utworzyć hierarchię widoku klienta, w której model widoku podstawowego przechowuje dane związane z wyszukiwaniem, a model widoku zstępującego uzupełnia szczegóły. .

Twoje żądania routingu może wyglądać tak:

GET - /Customer/     retrieve multiple customers 
            (supplying OData parameters in query string) 
GET - /Customer/{id}    retrieve a single customer 
PUT - /Customer/{id}    edit customer 

Co to wygląda to trzeba to dwie drogi, jedna ApiController dla klienta, a trzy metody żądania za to, co opisane. Nie polecam oddzielnego ApiController dla OData, ponieważ funkcjonalność zależy od obiektu.