Расчеты в бизнес-слое или контроллерах Для просмотра конкретной информации

Question

Я создаю веб-приложение ASP.Net MVC с использованием подхода n-уровня. Моя структура выглядит следующим образом:

Business Objects - Model 
Data Access Layer - DAL 
Business Logic Layer - BLL 
Mapping Layer 
ViewModels 
Controllers 
Views 

Я обычно ставлю расчеты в бизнес-уровне, но что расчеты, которые используются только для целей презентации? Например, при представлении в моем приложении я показываю счет-фактуру, любые сделанные платежи и баланс. Balance Owing - расчетная сумма. Поскольку я часто использую Balance Owing в своем приложении, я склонен создавать общий метод BalanceOwing в моем BLL, но есть и другие случаи, когда расчет только когда-либо будет использоваться для одного представления. В этом случае следует ли вместо вычисления перейти в контроллер или в моем случае слой отображения? (У меня есть слой отображения, который я использую для преобразования моделей доменов в viewmodels, что делает контроллер более аккуратным).

Действительно ли это разделительная линия? То есть, если я могу обобщить расчет и использовать его более одного раза, он должен идти в BLL, но если он специфичен для одного представления, он должен быть в контроллере или картографе?

РЕЗЮМЕ:

Я пошел с @ trailmax отвечает, потому что он видел, что некоторые вещи, которые я думал, как логика представления были в бизнес-логике фактов и, следовательно, принадлежат к УСКУ. В тех случаях, когда что-то действительно представляет собой логику представления и включает вычисления, такие как разбиение на страницы, я бы поставил их в класс полезности или метод расширения, как указано в @ramiramilu.

Answer 1

Все сводится к тому, что вы считаете «специфичным для просмотра». Если это расчет разрешения экрана или версии браузера - тогда абсолютно. Если вы говорите о длительности, которая достаточно проста, я бы подумал дважды. Это может выглядеть просто, но на самом деле в будущем может развиться - просто держите его в BLL.

В комментариях вы упомянули продолжительность периода. Это может выглядеть просто сейчас (End - Start).Date. Но это может развиться позже, чтобы рассчитать продолжительность этого периода, исключая выходные (например). И это определенно BLL, даже не слой Mapping.

Я сделал представления с встроенной логикой. И затем я видел, как эти взгляды развиваются. Это было некрасиво. Завершено потрошение ВСЕ логика из представлений и размещение этого в QueryHandler<T>. Поэтому мое эмпирическое правило - делать все вычисления в BLL (или обработчиках запросов, если вы используете CQRS). И просто дайте подготовленные данные для просмотра. (Также этот подход минимизирует потребность в слое отображения). Таким образом, ваше представление имеет только единую ответственность - отображать данные в требуемом формате.

Что касается слоя отображения, снова я предпочитаю иметь там минимальную логику. Я допускаю, чтобы DateTime был преобразован в String в формате 2 Feb 2014, но ничего больше, и вы снова в беде.

Пейджинг - это распространенная концепция. На самом деле это не бизнес-логика, но также не несет ответственности за представление. Но поскольку он настолько глубоко проникает в приложение, он все равно заканчивается BLL (или обработчиками запросов в нашем случае).

Answer 2

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

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

, если я могу обобщить расчет и использовать его больше, чем когда-то ему следует идти в УСК,

Не совсем, если расчет имеет бизнес актуальность и важность, то она должна идти в BLL. Или же он должен оставаться на уровне презентации.

Answer 3

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

Answer 4

Я не поклонник какой-либо реальной логики в контроллерах. Поэтому я бы переместил его в существующий BLL или даже новый компонент в BLL, если вы хотите сохранить его отдельно.

Причины, по которым я использую этот подход, - это два раза.

Во-первых, такая логика, как правило, выходит из-под контроля, и это будет действительно загромождать действия вашего контроллера. Мне нравится, чтобы они были очень краткими.(Обычно у меня есть три вещи: аутентификация, восстановление данных, конструкция ViewModel, каждая из которых достигается путем вызова индивидуального метода в некоторой форме BLL.)

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

Answer 5

Общая функция, написанная как служебная функция и используемая в бизнес-слое, должна помочь. Снова услышите от других людей