Избегайте больших контроллеров в MVC - PullRequest
2 голосов
/ 15 января 2010

Контроллеры могут стать большими и громоздкими, если они содержат большое количество действий. Является ли это серьезной проблемой при использовании в реальном мире, и если да, то каковы стратегии по ее смягчению (или она достаточно хороша, чтобы просто уменьшить счет действий на контроллер)?

Вдобавок ко всему, я могу представить себе, как контроллер перегружает логику для реализаций действий других типов, сгруппированных в соответствии с какой-то значимой эвристикой.

1 Ответ

3 голосов
/ 15 января 2010

По моему опыту, это в основном происходит, когда я не применяю нож "REST" достаточно агрессивно. Иногда метафора не соответствует тому, как мы думаем о проблеме; например, легко представить, что «вход в систему» ​​- это действие над «учетной записью», но если вы примените нож REST, вы поймете, что вход в систему действительно «начинает новый сеанс», и вы инвертируете идею, применив «новый». "(или Создать) действие на SessionController. Затем у вас есть небольшой контроллер, отвечающий за создание и уничтожение сеансов (вход и выход из системы).

Я уверен, что некоторые люди не будут увлекаться грязной водой REST с грязной концепцией аутентификации, поэтому давайте рассмотрим более очевидный пример. У меня может быть сущность BlogPost, и она может иметь кучу комментариев. Вместо того, чтобы иметь действие AddComment в BlogPostController, у меня есть обычные методы create / edit / delete для BlogPost и другой контроллер CommentController, чьи новые / create действия ожидают BlogPostId и реализуют методы create / edit / delete.

Я сталкивался с некоторыми ситуациями, когда мне требовалось действие, не похожее на REST, такое как «импортировать список X из файла CSV», каждая из которых принадлежит Y; «список» не очень важен в качестве концепции домена, поскольку я просто пытаюсь добавить существующую коллекцию Xes. В этом случае я принял немного уродливый подход, добавив в свой XController действие «import». Этот код является самым грязным кодом в любом из моих контроллеров, и я был бы склонен разделить его на что-то с более ограниченной ответственностью (возможно, класс XImporter), но сейчас он «работает». Я уверен, что кто-то умнее меня найдет лучшее решение.

Итак, мой аргумент таков: если у вас много действий, не связанных с RESTy, это своего рода запах кода; возможно, вы не моделируете то, что правильно контролируете. Но, если вы скажете, 1-3 нерешительных действия и попытки переосмыслить проблему не ведут вас в правильном направлении, возможно, об этом не стоит беспокоиться.

...