В веб-приложениях информация для входа в систему обычно хранится в сеансе, но как насчет приложений Windows? Использует ли синглтон правильную вещь? Должен ли я просто использовать статическое свойство?
Предположим, что я храню данные для входа в статическом свойстве ApplicationController. LoggedInUser. Когда пользователь входит в систему успешно, это свойство установлено. Перед успешным входом в систему LoggedInUser возвращает значение null. Затем, вызывая пример OrdersService из моего класса OrderListPresenter, я использую LoggedInUser как параметр.
var service = new OrdersService();
var orderCollection = service.GetOrdersByUserID(
ApplicationController.LoggedInUser.ID);
Хорошо, это работает, но это также затрудняет запись аппаратных тестов. Мне не нравится работать с одиночными/статическими членами из моих модульных тестов.
Возможно, я мог бы добавить ApplicationController в каждый класс, который должен получить доступ к зарегистрированному пользователю? Любые другие идеи?
Как вы думаете, лучший способ справиться с этим?
Инъекция - хороший ответ. Вероятно, вы найдете другие полезные вещи, чтобы добавить ApplicationController
, и это упростит модульное тестирование.
Я бы создал объект CurrentContext, который содержит поле CurrentUser и передал его всем моим ведущим.
Избежать синглтона, что может быть проблематичным для unit test или если вы решите позже расширить свое приложение.
В зависимости от того, что вы хотите сделать с идентификатором пользователя, рассмотрите возможность его размещения на System.Threading.Thread.CurrentPrincipal. Если ваше приложение имеет разрешение SecurityPermissionFlag.ControlPrincipal, тогда просто установите CurrentPrincipal, когда он у вас есть. Также обратите внимание, что System.Environment.UserName имеет зарегистрированное имя пользователя Windows.
Всегда есть необходимость перекручивать свой собственный тип, когда встроенный тип уже существует и делает то, что вам нужно (или близко к чему).