Здравствуйте, 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

Попробую выделить тему из Re[26]: QueryObject

Автор: IT
Дата: 08.02.13

, может что путное выйдет.


Ниже будут утверждения на которые можно возражать, а можно пропустить мелкие огрехи Но не в этом суть сообщения, суть другом:

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

Особенно интересует меня вещи, которые можно вынести в инфраструктуру проекта (т.е. логику которая никак не завязана на проект и может быть без изменений перенесена в другой).
Я приветствую ответы от всех, не только от IT).


A>>Мне сложно говорить за Игоря, но я 100% уверен, что в случае FatController-a, большая часть логики переедет из контроллера в другие классы/методы.
IT>В слове FatController ключевое слово — Fat. И это означает, что у нас просто много функционала в одном месте. Если этот функционал переместить в BL, то мы получим FatBL. Вот и вся разница.
О, давай рассмотрим эту тему. Глядишь и извлеку каку-то пользу из этого бесполезного топика.

Хотя этот термин (FatController) я увидел прямо здесь, но в принципе, я понимаю что это. Хотя не уверен, что у нас с тобой общее видения вопроса.


Я не согласен, что в FatController-е весь функционал -- это бизнесс логика. Дай бог там ее 20%.
Вот если взять, например, ASP net MVC, то в контроллер можно напхать:
1) Валидацию пользовательского ввода
2) Авторизацию, аутентефикацию
3) Получение данных о текущем пользователе
4) Саму бизнесс логику

Что с этим можно сделать:
1) вынести в валидацию модели и дата биндеры
2) выносим ее в инфраструктуру
3) опять инфраструктура: выделить базовый класс контроллера с данными о пользователе AuthenticatedUserControllerBase (название страшное, но суть понятна, думаю)
4) пока ничего делать не будем

Даже если после всего вышеперечисленного в контроллере останется много логики (тут она как раз бизнесс логика), то можно посмотреть на функционалность: а не много ли мы делаем в этом месте. Скорее всего пользователю так же неудобно работать с этим, скажем, сценарием ("экраном", операцией). Может нужно разбить этот сценарий на части и получить несколкьо контроллеров.

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








СУВ, Aikin

Здравствуйте, 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