Winforms: доступ к свойствам класса во всем приложении - PullRequest
Новая
       27

Winforms: доступ к свойствам класса во всем приложении

3 голосов
/ 11 августа 2009

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

У меня есть приложение winforms .net 3.5 c #, которое предоставляет пользователю форму входа при запуске приложения. После успешного входа в систему я хочу убежать в БД, получить некоторые пользовательские данные и сохранить их (в свойствах) в классе с именем AppCurrentUser.cs , который может быть доступен для всех классов. в сборке - цель здесь в том, чтобы я мог заполнить некоторые свойства однократным чтением данных, вместо того, чтобы каждый раз вызывать БД. В веб-приложении я обычно использую переменные сеанса, и я знаю, что концепция этого не существует в WinForms.

Структура класса похожа на следующую: 

public class AppCurrentUser {

    public AppCurrentUser() { }

    public Guid UserName { get; set; }
    public List<string> Roles { get; set; }
    public string Firstname { get; set; }
    public string Lastname { get; set; }
}

Теперь у меня есть несколько вариантов, по которым мне нужен совет специалиста:

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

Логически я считаю, что эти свойства должны быть статическими, так как я буду использовать класс один раз во всем приложении (и не , создающий его новые экземпляры), и это свойство значения будут "сброшены" при закрытии приложения. (Если я создаю его экземпляр, я могу избавиться от него при закрытии приложения)

Как мне структурировать свой класс и как получить доступ к его свойствам во всех классах в моей сборке? Я действительно буду признателен за ваш честный и ценный совет по этому вопросу!

Спасибо!

Ответы [ 4 ]

5 голосов
/ 11 августа 2009

Используйте шаблон синглтона здесь: 

public class AppUser
{
    private static _current = null;
    public static AppUser Current
    {
        get { return = _current; }
    }

    public static void Init()
    {
        if (_current == null)
        {
            _current = new AppUser();
            // Load everything from the DB.
            // Name = Dd.GetName();
        }
    }

    public string Name { get; private set; }
}

// App startup.
AppUser.Init();

// Now any form / class / whatever can simply do:
var name = AppUser.Current.Name;

Теперь "статичные" вещи не безопасны для потоков. Я оставлю это в качестве упражнения для читателя, чтобы выяснить, как правильно использовать синтаксис lock (), чтобы сделать его поточно-ориентированным. Вам следует также обработать случай, если свойство Current доступно до вызова Init.

1 голос
/ 11 августа 2009

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

Вы также можете использовать Dependency Injection, чтобы каждый раз, когда вы запрашиваете пользовательский объект, инфраструктура внедрения зависимостей (например, StructureMap ) предоставит вам нужный объект. - вы, вероятно, можете использовать его как переменную сеанса, так как вы будете работать в среде с состоянием.

0 голосов
/ 11 августа 2009

Я не уверен, что это правильный путь, но вы могли бы сделать что-то вроде этого (кажется, что вы все равно просите): 

public class Sessions
{
    // Variables
    private static string _Username;

    // properties
    public static string Username
    {
        get
        {
            return _Username;
        }
        set
        {
            _Username = value;
        }
    }
}

на случай, если c # не так ... я разработчик на vb.net ...

тогда вы просто используете Sessions.USername и т. Д.

0 голосов
/ 11 августа 2009

Правильное место для хранения этого типа информации находится в пользовательской реализации IIdentity. Любая информация, которая необходима для идентификации пользователя или его прав доступа, может храниться в этом объекте, который затем связывается с текущим потоком и может запрашиваться из текущего потока при необходимости.

Этот принцип показан в CLSA книгах Рокки Лотки или в пользовательской идентификации Google winforms.

...