Слабая ссылка против разрешения Autofac?

Question

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

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

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

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

Во-вторых, WeakReference, где я проверяю .IsAlive, чтобы посмотреть, могу ли я просто вернуть .Target или мне нужноразрешить хранилище и вызвать Find, и сделать WeakReference с тем, что я получил.

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

Мысли?

Редактировать: Принимая все время / усилия, которые нужны репозиторию для ответа .find - меня больше интересует, что дороже, WeakReferenceс накладными расходами или разрешением AutoFac.

Answer 1

Мне просто интересно, что больше накладные расходы - WeakReference или повторяется Резолюции IoC для репозиториев.

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

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

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

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

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

Answer 2

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