Блог

1. Существует ли общее эмпирическое правило организации контроллеров?

2. Должны ли контроллеры создаваться только в том случае, если они связаны с моделью предметной области?

Например, если у меня есть модель ‘Product‘, у меня будет ProductController, который будет иметь такие действия, как ‘GetProductDetails‘ и т.д…

Но как насчет вещей, которые не имеют реальной модели, таких как поиск продуктов и возврат нескольких продуктов на странице?

Поскольку модель продукта является базовой моделью для всех этих взаимодействий, должна ли эта функциональность быть включена в ProductController и иметь действия для поиска и отображения нескольких продуктов, или должен быть создан другой для поиска?

Если вы будете следовать шаблону, используемому строительными лесами, используемыми в Visual Studio, то да, в итоге у вас будет один контроллер на объект, поэтому контроллер продукта будет иметь действия, которые возвращают список, один продукт и действие для публикации обновлений. Кроме того, у вас могут быть дополнительные действия по поиску и любые другие действия, связанные с продуктом. Который просто указывает и подкрепляет ответ вывода.

Однако причина, по которой вы бы это сделали, заключается в том, что это означает, что ваш код проще поддерживать — если вы ищете код для работы с продуктами, у вас есть один класс контроллера для просмотра. Вы также придерживаетесь принципа разделения задач, каждый контроллер связан только с одним типом объекта.

В дополнение к этому, если ваше приложение становится намного больше, и вы используете шаблон внедрения IoC / зависимостей, вам нужно ввести только один репозиторий или бизнес-сервис на контроллер, который является поисковым контроллером, который предлагает методы поиска продуктов, и клиентам понадобятся сервисы или репозитории для клиентов и продуктов, но запрос может быть толькопоиск клиентов, поэтому создание репозитория продуктов было бессмысленным, поэтому вы получаете неэффективный и чрезмерно сложный код. Существуют шаблоны для решения этой проблемы, но они требуют еще большего количества кода, поэтому, чтобы избежать этого и упростить его, придерживайтесь одного корневого объекта one controller.

Вы должны управлять каждым действием, которое включает один и тот же ресурс с одним и тем же контроллером, и вы должны реализовать это решение в соответствии с моделью зрелости Ричардсона

Модель (разработанная Леонардом Ричардсоном), которая разбивает основные элементы подхода REST на три этапа. Они представляют ресурсы, http-глаголы и элементы управления гипермедиа.

итак, ваш API будет примерно таким:

GET /api/products Получает полный список всех категорий

GET /api/products/123 Получает сведения для одной категории

PUT /api/products Заменяет весь список категорий на заданный

PUT /api/products/123 Обновляет указанную категорию

POST /api/products создает новую категорию

УДАЛЕНИЕ /api/products Удаляет все категории

DELETE /api/products/123 Удаляет указанную категорию