Область структуры структуры / руководство жизненным циклом?

Question

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

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

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

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

Спасибо за понимание,

Phil

Answer 1

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

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