Здравствуйте, Aikin, Вы писали:

A>Я не согласен, что в FatController-е весь функционал -- это бизнесс логика. Дай бог там ее 20%.
A>Вот если взять, например, ASP net MVC, то в контроллер можно напхать:

Да, лучше конкретно на конкретном инструменте. А то сейчас опять уйдём в теорию и назад не вернёмся.

A>1) Валидацию пользовательского ввода

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

A>2) Авторизацию, аутентефикацию

Эти вещи традиционно делаются средствами инфраструктуры, кроме некоторых нюансов.

A>3) Получение данных о текущем пользователе

В инфраструктуру.

A>4) Саму бизнесс логику

Я пишу бизнес логику в контроллере до тех пор пока не начинаю чувствовать дискомфорт. Потом по ситуации. Бью на части, выношу в сервисные модули. Linq позволяет оформлять в виде отдельных методов части сложных запросов. Использую и такое. В общем, обычные техники повторного использования кода.

A>Что с этим можно сделать:
A>1) вынести в валидацию модели и дата биндеры

Если параметры запроса принимаются в виде объекта, то можно вынести и туда. Но это всё равно не пройдёт мимо контроллера. К тому же остаётся проверка валидности объекта в пределах системы. Но даже в этом случае сделать нечно универсальное и самодостаточное вряд ли получится или получится за счёт неэффективных решений. Допустим, валидное состояние объекта определяется полями A, B и C. Например, наименование товара не должно быть пустым, его ID должен быть уникальным в пределать системы и его количество на складе должно быть не меньше нуля. Понятное дело, что если наш функционал работает только с количеством, то валидировать названия и нормера смысла нет, а фанатичное следование требованию валидировать всё всегда приведёт только к проблемам.

A>2) выносим ее в инфраструктуру

Кроме случаев, когда логика строится взависимости от ролей пользователй.

A>3) опять инфраструктура: выделить базовый класс контроллера с данными о пользователе AuthenticatedUserControllerBase (название страшное, но суть понятна, думаю)

Можно и так. Можно сделать метода расширения для HttpContextBase. А можно и так и эдак.

A>Если и дальше логики в контроллере останется много, тогда и выносить ее куда-то. Но не факт, что для этой логики будет отдельный слой, а тем более сборка.

You got it