2009-06-08 2 views
11

Мы разрабатываем приложение .NET 3.5 Windows Forms, используя LINQ to SQL и MVP. У нас есть DataRepository класс для извлечения данных:Использование статической переменной для кэширования данных

public class DbUserRepository : IUserRepository 
{ 
    private IList<UserName> _users; 

    public IList<UserName> GetUserNames() 
    { 
    if (_users == null) 
    { 
     // retrieve _users from DB 
    } 

    return _users; 
    } 

Для того, чтобы кэшировать список пользователей во всех экземплярах DBUserRepository, мы будем использовать Caching Application Block Энтерпрайза библиотеки.

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

private static IList<UserName> _users; 

Благодаря

ответ

10

Самая большая нижняя сторона этого делает именно то, что означает static; хотя у вас может быть много объектов DbUserRepository, они всегда будут делиться только одной переменной _users. Случаи, когда это вызывает проблемы:

  • Если ваше приложение когда-либо становится многопоточным, и вы хотите, чтобы каждый поток, чтобы иметь свой собственный репозиторий отчетливого пользователя (или это не является проблемой, зависит от того, что означает, что хранилище в контекст вашей системы)

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

3

для простого кэширования я думаю статической переменной хорошо, просто нужно быть немного осторожным об использовании замков для защиты нескольких потоков к переменной _users. Однако лучшим подходом может быть использование класса кэша ASP.NET. Я знаю, что это в пространстве имен System.Web, но вы можете use it outside of ASP.NET application too.

3

пару вещей, чтобы рассмотреть.

  1. Потокобезопасность инициализации переменной
  2. AppDomains. Статические переменные являются локальными для экземпляра AppDomain. Поэтому, если у вас есть несколько приложений AppDomains, у вас будет несколько экземпляров кеша

Это может быть или не быть интересным для вашей заявки. Наверное, нет, но стоит отметить.

0

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