Направление структуры/руководства жизненного цикла?

Question

Есть ли причина переключиться с области по умолчанию (переходная?) На что-то еще, за пределами необходимости контролировать область по функциональным причинам (например, Singleton)?

Если я придерживаюсь области по умолчанию, каждый экземпляр по умолчанию каждого типа плагина будет эффективно создаваться при каждом запросе (при условии, что веб-приложение), это правильно? Может ли это повлиять на производительность заметно?

Я рассмотрел возможность использования области Http Session для ограничения этого на один экземпляр для каждого зарегистрированного пользователя. Однако это приведет к (по крайней мере) одному экземпляру каждого типа плагина, хранящемуся в памяти для каждого пользователя в любое время. Используя область по умолчанию, эти экземпляры будут храниться только в памяти во время обработки запроса на страницу. Я не уверен, что предпочтительнее.

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

Спасибо за любую проницательность,

Phil

Answer 1

Я оставляю область по умолчанию на месте. Это означает, что для каждого запроса (либо каждым пользователем, либо многими пользователями) у меня есть экземпляр объекта в руке. Это означает, что каждый раз создается новый запрос. Сохранение его в сеансе - это то, что я предпочитаю иметь более конкретный контроль. По этой причине я могу бросить слой кэширования поверх уровня сервиса и вставить в него объект StructureMap. Затем я могу запросить кеш для уже созданного (теперь сериализованного) объекта и выбрать, откуда взять мои объекты.

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