Блог

У меня есть объекты POCO, которые ссылаются друг на друга, находя идентификаторы в репозиториях. Я не хочу, чтобы объекты имели сильные ссылки друг на друга, потому что в репозиториях есть политика кэширования, которая может удалять объекты. Другие объекты, которые ссылаются на них, должны просто перезагрузить их через репозиторий. Я использую AutoFac в качестве своего контейнера IoC.

Очень простой пример — объект Region ссылается на объект Currency:

 class Region
{
    ...
    public Currency GetCurrency()
    {
        ... Get the right Currency object
    }
    ...
}
  

Я экспериментировал с двумя способами сделать это. Первый — просить AutoFac каждый раз разрешать хранилище валют, чтобы я мог вызывать Find (id).

Второй — это WeakReference , где я проверяю .Я хочу посмотреть, смогу ли я просто вернуться.Цель или если мне нужно разрешить репозиторий и вызвать Find, и сделать слабую ссылку на то, что я получил.

Я изучал небольшие накладные расходы, которые накладывает WeakReference, но я не уверен, как это сравнить с тем, чтобы каждый раз запрашивать разрешение AutoFac.

Мысли?

Редактировать: репозиторию требуется столько времени / усилий, чтобы ответить на .найти — меня больше интересует, что дороже, WeakReference с его накладными расходами или автоматическое разрешение FACT.

Мне просто интересно, что является более накладным — слабая ссылка или повторяющиеся разрешения IoC для репозиториев.

На этот вопрос трудно ответить, потому что эти два решения выполняют совершенно разные задачи. Накладные расходы также сильно зависят от того, как вы будете регистрировать / разрешать компонент с помощью autofac.

Например: планируете ли вы зарегистрироваться как InstancePerLifetimeScope() и получить ссылку на Lazy?

При использовании weakreference вы сохраняете ссылку на объект, но сообщаете среде выполнения, что ее можно собирать — с этим вы справитесь.

С помощью autofac вы просите контейнер создавать и предоставлять экземпляры, внедрять зависимости, а также (возможно) управлять областью действия и удалением.

Что касается накладных расходов — небольшая область, где эти две проблемы пересекаются (получение экземпляра чего-либо), полностью зависит от того, как вы регистрируете и разрешаете компонент, но я не вижу ни одного пути к коду, где у WeakReference не было бы немного (совсем немного) меньше накладных расходов. Однако у WR немного больше накладных расходов во время выполнения, поэтому его трудно сравнивать напрямую.

Обращение к базе данных всегда требует гораздо больших затрат, чем работа со слабой ссылкой. Для этого конкретного примера валют существует всего несколько объектов, поэтому вам лучше всего хранить их все в памяти, но для больших наборов данных двухуровневый подход (weakreference repository) кажется разумным.