Как разместить REST методы в контроллере?

Question

[Tsiren Naimanov]

У меня всего 22 объекта, для каждого нужно написать get вьюшку, и методы реста post (добавление, обновление, удаление, просмотр)
у меня 3 основных контроллера созданы по смыслу, так скажем
в каждом по 5-10 сущностей.
Что лучше, продолжать так делать, либо для каждой сущности создавать контроллер с вьюхой и post методами???

Answer 1

[Станислав Макаров]

Контроллеры - это ваши проекции сущностей в сервисе (грубо говоря, объектов ваших классов бизнес-логики) на ресурсы веб-API, предоставляемого сервисом. Какие сущности проецировать на ресурсы, а какие - нет, целиком зависит от того, какое API вы хотите получить в конечном счете. В каких контроллерах это делать и стоит ли разбивать N контроллеров на M контроллеров - зависит от того, как вам удобно их реализовывать. Ну это примерно то же самое, что спросить "стоит ли разбивать 5 классов на 10?". У каждого контроллера - своя ответственность. Если вы четко понимаете ответственность каждого контроллера - разбивать не надо. Если вы перестали понимать и какой-то контроллер начал делать слишком много разных вещей - надо разбить.

Нужно понимать, что лучше сначала спроектировать интерфейсы взаимодействия крупных компонент: клиентов и сервисов, а потом уже эти интерфейсы реализовывать. В случае REST, вы сначала проектируете REST API, исходя из задач вашего приложения, а потом уже реализуете сервис и клиент.

методы реста post (добавление, обновление, удаление, просмотр)

вот этой фразы не понял.

Comments

[Tsiren Naimanov]

ну то есть у меня будут методы HttpPost Add update delete details примерно такие

[Tsiren Naimanov]

Спасибо за ответ :) я вот разбил на 3 контроллера, каждый со своей темой так скажем
а буду ли я разбивать ещё эти 3 на несколько увидим тогда дальше
ещё один вопросик
стоит ли так делать:
есть сайт aspnet mvc там всё логика и т д, а например взаимодействие с БД, использовать другой например проект aspnet API конкретно.
То есть запросы юзать уже от одного веб приложения к другому, ну то есть пользователи не увидят какой конкретный запрос пойдёт к приложению с бд, и я ДУМАЮ что так безопаснее...

[Станислав Макаров]

Tsiren Naimanov я понял вас так: клиент --http--> asp.net mvc --http--> asp.net web api --> БД.
Если так, то если честно, не вижу смысла в таком усложнении. Бэкенд на то вам и нужен, чтобы реализовывать бизнес-логику и работать с базой. В принципе, бывают случаи когда это может быть полезно, но во-первых тогда между MVC-сайтом и промежуточным API нет особо смысла использовать HTTP (можно поискать более подходящий и легкий протокол), а во-вторых вам скорее всего это не нужно.

Если у вас часть контроллеров возвращают вьюшки, а часть - только JSON (т.е. работают как API-контроллеры), это совершенно нормально. Более того, если вы напишите сайт как SPA, то только API-контроллеры и останутся у вас (можно считать это вырожденным случаем).

Такую схему как вы предложили используют, когда один сервис обращается к другому, и между ними нет доверительных отношений - например, какой-нибудь новостной агрегатор обращается к первоисточнику новостей. Ну или например централизованный сервис бронирования отелей обращается к API конкретной сети отелей при бронировании номера. Тогда подобная схема складывается естественным образом, т.к. оба сервиса существуют самостоятельно и в общем случае не собираются давать друг другу непосредственный доступ к БД. А вы сами пишите свое приложение.

P.S. Если вы хотите сделать обыкновенную Class library DLL-ку, и убрать туда сущности и бизнес-логику, ORM-маппинги - это другое дело, это можно.

[Tsiren Naimanov]

Станислав Макаров: Спасибо!!! :)
у меня нету web api, но я думал его создавать, теперь уже не буду :)
Большое спасибо за ясность :)