Должен уровень Business приложения смочь получить доступ к объекту Сессии?

Нет. Если у вас был слой «Контроллер», вы должны получить к нему доступ там. Получите все необходимое от сеанса и передайте его своему бизнес-уровню.

Мне странно пахнет. Может быть, вам нужен уровень представления для управления сеансом и любой другой информацией о состоянии?

Я считаю ненужное использование сеанса запахом кода в целом, часто строки запроса, файлы cookie и состояние просмотра легче и имеют лучшую «область действия»

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

Например, в консольном приложении, веб-приложении ASP.NET, службе Windows, и приложение Windows Forms - только ASP.NET имеет сеанс.

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

Исключение составляет модульное тестирование. Исполнители тестов nUnit представляют собой другой пользовательский интерфейс, и их сложно моделировать запрос, ответ, сеанс, приложение и т. д.

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

Вздох.

Широкого консенсуса не будет; бизнес-уровень и уровень контроллера / веб-уровня должны поддерживаться по-разному, потому что это разные задачи.

Дело в том, что вы, кажется, называете это вопросом «чистота против реальности», что невероятно недальновидно и немного неприятный. Это также бросает вызов сути вопроса; Если вы не собираетесь рассматривать представленные мнения, тогда зачем их запрашивать?

Это правда, что более тщательное разделение вещей требует больше предварительных усилий, больше времени и, в конечном итоге, может стоить немного больше . Также верно, что вы не сможете ощутить немедленную выгоду от этого. Однако множество слезливых историй, которыми на протяжении нескольких десятилетий делились огромное количество программистов, предполагает, что там, где это возможно, ваш так называемый " данные клиента в приложении командной строки или навигация по многостраничной веб-форме с данными, хранящимися в сеансе. Допустим, вы выбираете последнее; наклеить на него веб-интерфейс. Теперь то, что вас интересует, - это написание относительно простого кода для обработки получения запрошенных данных и их представления пользователю. Дело в том, что ваше веб-приложение; внешний интерфейс, , что - это весь ваш пользовательский интерфейс; сеансы и все. Только в тот момент, когда вы готовы сказать: «Эй, давайте вставим эти данные о клиентах в базу данных», вы переходите и вызываете эти с любовью созданные уровни сервисов, передавая каждый бит информации, которую получает ваше веб-приложение. спрятал; пользовательский ввод, имя пользователя, производящего изменение; все это дерьмо. И ваш уровень обслуживания имеет дело с этим. Или, как вариант, суки ' потому что вы забыли обязательное поле.

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

Потребность добавить новое правило проверки? Нет проблем; сделать так, чтобы уровень сервиса выполнял проверку и обрабатывал проблемы пользовательского интерфейса по мере необходимости на более высоких уровнях цепочки. Нужно что-то изменить ' s рассчитано? Измените это на бизнес-уровне. Больше ничего менять не нужно.

Если вы сохраните три перечисленных уровня, уровень «Бизнес», вероятно, будет наиболее подходящим для работы с объектами сеанса.

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

Я думаю, это зависит от использования, но да, мы постоянно получаем доступ к сеансу с нашего бизнес-уровня. Здесь тоже есть аргумент «чистота против реальности».

Например, в нашем приложении у нас есть база данных для каждого клиента, но одна база кода. Итак, у нас есть информация о клиенте в сеансе для каждого пользователя. Конечно, Затем мы могли бы извлечь эти данные из сеанса на веб-уровне, а затем передать их на бизнес-уровень. Конечно, бизнес-уровень даже не заботится об этом, но он нужен уровню данных для подключения к правильной базе данных. Таким образом, бизнес-уровень должен будет передать его на уровень данных. Похоже на передачу большого количества параметров без уважительной деловой причины. В нашем случае наш уровень данных проверяет объект сеанса на наличие строки подключения и запускается оттуда. Мы закодировали проблему отсутствия сеанса, если это не веб-приложение (а у нас есть службы Windows и вспомогательные приложения .exe), следующим образом:

protected virtual string GetConnectionString()
{
string connectionString;
string connectionStringSource;

//In app.config?
if (ConfigurationManager.AppSettings[_ConnectionStringName] != null &&
   ConfigurationManager.AppSettings[_ConnectionStringName] != "")
{
   connectionString = ConfigurationManager.AppSettings[_ConnectionStringName];
   connectionStringSource = "Config settings";
}
//Nope? Check Session
else if (null != HttpContext.Current && null != HttpContext.Current.Session &&
   null != HttpContext.Current.Session[_ConnectionStringName])
{
  connectionString = (string)HttpContext.Current.Session[_ConnectionStringName];
  connectionStringSource = "Session";
}
//Nope? Check Thread
else if (null != System.Threading.Thread.GetData(
      System.Threading.Thread.GetNamedDataSlot(_ConnectionStringName)))
{
   connectionString = (string)System.Threading.Thread.GetData(
          System.Threading.Thread.GetNamedDataSlot(_ConnectionStringName));
   connectionStringSource = "ThreadLocal";
}
else
{
   throw new ApplicationException("Can't find a connection string");
}

if (debugLogging)
   log.DebugFormat("Connection String '{0}' found in {1}", connectionString, 
          connectionStringSource);

return connectionString;
}

Доступ к сеансу с бизнес-уровня определенно является запахом кода.

Если вам нужно «переключить» бизнес-уровень, как указано, ваш уровень представления или контроллер - это все, что нужно для беспокойства о том, что такое переменная сеанса.

Например, предположим, вы хотите использовать один набор объектов для одной переменной сеанса, а другой набор для другой переменной. Ваш контроллер может вызвать уровень сервиса и передать переменную. Уровень сервиса затем вернет соответствующий бизнес-объект.

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

Объект сеанса привязан к конкретной реализации пользовательского интерфейса, поэтому смерть вашего бизнес-уровня из-за сеанса - это запах.

Кроме того, вы, вероятно, сможете провести модульное тестирование своего бизнеса слой - как вы собираетесь это сделать, если в сеансе есть зависимости?