Архитектура NLayers - Является ли пользовательский сеанс компонентом CrossCutting? Как мы можем это реализовать? - PullRequest
Новая
       24

Архитектура NLayers - Является ли пользовательский сеанс компонентом CrossCutting? Как мы можем это реализовать?

1 голос
/ 08 сентября 2011

Предполагается, что у нас N-уровневая архитектура (пример: представление, домен, постоянство).Уровень представления - это веб-приложение, но мы должны помнить, что мы могли бы повторно использовать домен и постоянство для другого уровня представления (например, веб-службы или приложения Windows).

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

Интерфейсы (или контракты) службы моего домена во всех его методах будут включать входной параметр "UserId", предоставленныйУровень представления (домен должен быть доверенным на уровне представления):

  • GetProfileInfo (userId)
  • GetUserPendingOrders (userId)

ИЛИ. Сеанс пользователядолжен быть компонент CrossCutting?Если это так, домен будет знать, какой пользователь вызывает его службу, поэтому интерфейс будет:

  • GetProfileInfo ()
  • GetUserPendingOrders ()

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

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

1 Ответ

0 голосов
/ 08 сентября 2011

Сеанс пользователя в классическом веб-контексте - это то, о чем знает только веб-сервер.

Вы можете иметь концепцию пользовательского сеанса в вашем приложении (как просто еще один вид объекта домена, с собственным хранилищем данных и т. Д.), Но вы просто должны быть осторожны, чтобы не связывать / тесно связывать.связать это каким-либо образом с веб-серверами концепции сеанса.

То же самое относится и к другим видам приложений (WinForms и т. Д.).

Идея идентификатора пользователя не связана с сеансом пользователя;уверен, что пользователь может использовать систему (создавая новый сеанс, и вы сможете связать две вещи вместе. (Ваши примеры выше заставили меня задуматься, не смутили ли вы их).

Это так?сквозная проблема?

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

В противном случае, если пользовательские сеансы являются не чем иным, как (например) сеансами на основе веб-сервера, тогда ответом является «нет», это зависит от концепциина уровне представления - работает на веб-сервере.

Тогда есть третий вариант, своего рода промежуточный дом: вы можете передавать SessionID пользователей точно так же, как и любой другой примитивданные - но на самом деле никогда не иметь объект домена пользовательского сеанса. Вы просто должны быть осторожны, например, один вид веб-сервера может использовать GUID, другойВозможно, вы должны использовать int или строку - так что будьте осторожны.

...