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

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

IT>Да, лучше конкретно на конкретном инструменте. А то сейчас опять уйдём в теорию и назад не вернёмся.
Я смотрю, что нужно еще конкретнее. Кусок кода. Потому как все равно теоретизирования получаются. Я попробую поискать.

A>>1) Валидацию пользовательского ввода
IT>О валидации я десять лет назад подробно распинался здесь. В принципе, с тех пор ничего не поменялось.
За ссылку спасибо. Я говорил про 1) и частично 2) остальное это чистая бизнесс логика и логика хранения данных.
IT>Валидность комбинации параметров и их соответствие другим параметрам системы кроме как в контроллере делать больше негде.
Если сильно придираться, то вообще вся логика в контроллере делается. Он "клей" для всех остальных подсистем.
IT>Ну или можно делегировать это каким-нибудь другим компонентам или встроить в бизнес логику, но это всё равно пройдёт через контроллер.
В этом и поинт топика. Куда можно переносить эту логику.

A>>2) Авторизацию, аутентефикацию
IT>Эти вещи традиционно делаются средствами инфраструктуры, кроме некоторых нюансов.
+1

A>>3) Получение данных о текущем пользователе
IT>В инфраструктуру.
+1

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


A>>Что с этим можно сделать:
A>>1) вынести в валидацию модели и дата биндеры
IT>К тому же остаётся проверка валидности объекта в пределах системы. Но даже в этом случае сделать нечно универсальное и самодостаточное вряд ли получится или получится за счёт неэффективных решений.
Как я уже сказал, имеется ввиду первоначальная проверка пользовательского ввода. Т.е. удостоверяемся что пользователь ввел адекватные значения и можно идти дальше.

A>>2) выносим ее в инфраструктуру
IT>Кроме случаев, когда логика строится взависимости от ролей пользователй.
Спасибо, хорошее замечание. Согласен, иногда имеет смысл кинуть исключение "нет прав" прямо в контроллере.

A>>3) опять инфраструктура: выделить базовый класс контроллера с данными о пользователе AuthenticatedUserControllerBase (название страшное, но суть понятна, думаю)
IT>Можно и так. Можно сделать метода расширения для HttpContextBase. А можно и так и эдак.
+1

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



ЗЫ Сорри что так долго отвечал. На работе запарка, а на выходных принципиально не выходил. Могло "засосать"

СУВ, Aikin