何时使用 Singleton、Transient、何时使用 Ninject 和 MongoDB 的 Request
当我在 global.cs 文件中进行绑定时，我不太确定何时应该使用 SingletonScope()、TransientScope() 和 RequestScope()。
例如，我对 MongoSession 的调用（使用 NoRM 和 mvcStarter 项目 http://mvcstarter.codeplex.com/) 设置为 SingletonScope，但我创建了一个存储库，它使用此 MongoSession 对象来使对 Mongo 的调用更容易，例如，我有一个 NewsRepository，它使用 MongoSession 从数据中获取我的新闻项。作为一个例子，我有一个调用，它获取 DisplayOnHome 设置为 true 的新闻项目，并按 CreationDate 获取最新的新闻项目。这样的存储库应该是 SingletonScope 还是 RequestScope 更合适？
我应该什么时候使用它们以及为什么？
I'm not quite sure when I should use SingletonScope() vs TransientScope() vs RequestScope() when I do my binding in my global.cs file.
I have for example my call to MongoSession (using NoRM and the mvcStarter project http://mvcstarter.codeplex.com/) which is set to SingletonScope but I created a repository that use this MongoSession object to make calls to Mongo easier, e.g., I have a NewsRepository which uses MongoSession to fetch my News items from the data. As an example I have a call that fetches News items that has DisplayOnHome set to true and get the latest by CreationDate. Should such a repository be SingletonScope or would RequestScope would be more appropriate?
When should I use each of it and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一般来说，在 Web 应用程序中，您希望状态尽可能成为请求范围。
仅在非常低级别的优化的情况下，您才可能遇到适合创建单例对象的情况（即使如此，您也有可能将此类缓存/共享逻辑拉出到另一个类中，该类会被拉入）作为对其他[请求范围]对象的依赖并使其成为单例范围）。请记住，Web 应用程序上下文中的单例意味着使用相同对象的多个线程。这很少是好消息。
同样，瞬态作用域是最直接的默认值（这就是 Ninject 2 这样做的原因）——仅当出于性能原因等原因需要共享某些内容时（或者因为这只是上下文），请求作用域才应纳入考虑范围。共享的[如其他答案中提到的]）。
In general in a web app, you want state to be request scope as much as possible.
Only in the case of very low level optimisations are you ever likely to run into a case where its appropriate to create singleton objects (and the chances even then are that you'll pull such caching / sharing logic out into another class which gets pulled in as a dependency on your other [request scope] objects and make that singleton scope). Remember that a singleton in the context of a web app means multiple threads using the same objects. This is rarely good news.
On the same basis, transient scope is the most straightforward default (and that's why Ninject 2 makes it so) - request scope should only come into the equation when something needs to be shared for performance reasons, etc. (or because that's simply the context of the sharing [as mentioned in the other answer]).
我想答案取决于您的
MongoSession是否代表一个工作单元。我使用过的大多数与数据库相关的类（主要是在 ORM 上下文中，例如 NHibernate 或 EF4）都围绕着表示工作单元的上下文、实体和跟踪状态。工作单元的保留时间不应超过执行给定工作单元所需的时间，之后应提交或回滚该单元。这意味着您应该使用RequestScope。如果您的
MongoSession不是一个工作单元，您可以在 MVC 会话的生命周期内保留它，在这种情况下，SessionScope将适当。I guess the answer would depend on whether your
MongoSessionrepresents a unit of work or not. Most database related classes that I've worked with (mostly in the context of ORM, such as NHibernate or EF4) revolve around a context, entities, and tracked state that represent a unit of work. A unit of work should never be kept around longer than the length of time required to perform the given unit of work, after which the unit should be committed or rolled back. That would mean you should useRequestScope.If your
MongoSessionis not a unit of work, you could keep it around for the lifetime of an MVC session, in which caseSessionScopewould then be appropriate.根据上面 @shankbond 请求的已删除问题，
Disposal 不一定像人们想象的那样在主请求线程上同步执行。
您可能想在请求中的适当阶段存储一个
Block，然后Dispose()它（您将如何处理异常？）看看 Ninject测试更多示例（说真的，去看看 - 它们简短而清晰，当我第三次听时我并没有后悔！）
请参阅 http://kohari.org/2009/03/06/cache-and-collect-lifecycle-management -in-ninject-20/
From deleted question as requested by @shankbond above
The
Disposal is not necessarily performed synchronously on your main request thread as one might assume.You probably want to stash a
Blockand thenDispose()it at an appropriate phase in your request (how are you going to handle exceptions?)Have a look in the Ninject Tests for more examples (seriously, go look - they're short and clear and I didnt regret it when I listened the 3rd time I was told to!)
See http://kohari.org/2009/03/06/cache-and-collect-lifecycle-management-in-ninject-20/