Общий вопрос по статическим элементам и по отношению к DI в репозиториях и провайдерах - PullRequest
0 голосов
/ 05 декабря 2010

Я просто хочу окончательно обернуть голову вокруг статичных / нестатических элементов навсегда.Я буду использовать мое приложение ASP.NET MVC 2 + Ninject + Repositories + Providers + Entity Framework в моих примерах.

Итак, предположим, что я связываю одноэлементный экземпляр моего контейнера EF в ядре Ninject., если у меня есть этот код, я увижу улучшения производительности или как именно это повлияет?

public class Repository<T> where T : class {
    //  private readonly DefaultContainer = null;
    //  REPLACED BY:
    private static readonly DefaultContainer = null;

    [Inject]
    public Repository(
        DefaultContainer DefaultContainer) {
        DefaultContainer = DefaultContainer;
    }
}

public class EmployeeRepository {
    //  private readonly DefaultContainer = null;
    //  REPLACED BY:
    private static readonly DefaultContainer = null;

    [Inject]
    public EmployeeRepository(
        DefaultContainer DefaultContainer) {
        DefaultContainer = DefaultContainer;
    }
}

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

Теперь, есть ли улучшение производительности, если его статический по сравнению с нестатичным?Я спрашиваю, потому что, читая через MSDN, я читаю, что статические члены выделяются только один раз, значит ли это, что у меня может быть 20 репозиториев в провайдере, и все они используют одинаковые DefaultContainer?Или это означает, что первый экземпляр Repository<T> будет выделять DefaultContainer, но затем все последующие репозитории T, где бы они ни создавались в приложении, будут использовать этот DefaultContainer?

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

Если это второй вариант, то не будет ли он также иметь повышение производительностикакой-то еще, даже если он будет выделен один раз для каждого Repository<T>, а не для каждого Repository<T> когда-либо?

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

Ответы [ 2 ]

3 голосов
/ 05 декабря 2010

Краткий ответ: нет, выигрыша в производительности нет.

Длинный ответ: Используя поле static, вы стираете, чья ответственность заключается в поддержании образа жизни вашей зависимости. Контейнеры, такие как Ninject, обычно имеют возможность разрешать что-то как одноэлементное или временное. Если бы вы решили, что ваш репозиторий (и DefaultContainer) должен быть временным, а не одноэлементным, но все еще иметь статическое поле, вы столкнетесь с довольно неприятным состоянием гонки, поскольку экземпляры последовательно перезаписывают общее поле.

2 голосов
/ 05 декабря 2010

Я рекомендую покончить со статическими элементами и позволить вашему контейнеру ioc управлять временем жизни объекта.Недавно я сделал серию постов в блоге, охватывающих большую часть этой же темы.Я использовал nhibernate вместо фреймворка.Вот ссылка, которая может представлять интерес:

http://blog.bobcravens.com/category/ninject/

Надеюсь, это поможет.

Боб

...