Когда использовать Singleton vs Transient vs Request с использованием Ninject и MongoDB

Я не совсем уверен, когда должен использовать SingletonScope() vs TransientScope() vs RequestScope(), когда я выполняю привязку в файле global.cs.

У меня есть, например, мой призыв к MongoSession (с использованием NoRM и проекта mvcStarter http://mvcstarter.codeplex.com/), который установлен на SingletonScope, но я создал репозиторий, который использует этот объект MongoSession, чтобы сделать звонки в Mongo проще, например, у меня есть NewsRepository, который использует MongoSession для извлечения моих новостей из данных. В качестве примера у меня есть вызов, который извлекает элементы новостей, для которых значение DisplayOnHome установлено равным true, и получать последние данные от CreationDate. Должен ли такой репозиторий быть SingletonScope или RequestScope был бы более уместным?

Когда я должен использовать каждый из них и почему?

Ответ 1

Как правило, в веб-приложении вы хотите как можно больше указать область запроса.

Только в случае очень низких оптимизаций уровня вы когда-нибудь столкнетесь с ситуацией, когда ее целесообразно создавать одноэлементные объекты (и даже если шансы на то, что вы вытащите такую логику кэширования/совместного использования в другой класс, вытягивается как зависимость от других объектов [области запроса] и делает Singleton scope). Помните, что singleton в контексте веб-приложения означает несколько потоков, использующих одни и те же объекты. Это редко бывает хорошей новостью.

На той же основе область с переходными процессами является самым простым дефолтом (и почему Ninject 2 делает это так) - область запроса должна входить только в уравнение, когда что-то должно быть разделено по соображениям производительности и т.д. (или потому, что просто контекст обмена [как указано в другом ответе]).

Ответ 2

Я думаю, ответ будет зависеть от того, является ли ваш MongoSession единицей работы или нет. Большинство классов, связанных с базой данных, с которыми я работал (в основном в контексте ORM, таких как NHibernate или EF4), вращаются вокруг контекста, сущностей и отслеживаемого состояния, которые представляют собой единицу работы. Единицу работы никогда не следует хранить дольше, чем время, необходимое для выполнения данной единицы работы, после чего устройство должно быть зафиксировано или откат. Это означает, что вы должны использовать RequestScope.

Если ваш MongoSession не блок работы, вы можете сохранить его в течение всего жизненного цикла MVC-сессии, и тогда будет подходящим SessionScope.

Ответ 3

Из удаленного вопроса в соответствии с требованиями @shankbond выше

Dispos al не обязательно выполняется синхронно на вашем основном потоке запроса, как можно было бы предположить.

Вероятно, вы захотите записать Block, а затем Dispose() на соответствующей фазе вашего запроса (как вы собираетесь обрабатывать исключения?)

Взгляните в Ninject Tests для получения большего количества примеров (серьезно, посмотрите - они короткие и понятные, и я не пожалел об этом, когда я слушал 3-й раз, когда мне сказали!)

См. http://kohari.org/2009/03/06/cache-and-collect-lifecycle-management-in-ninject-20/