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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

---

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

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

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

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