Ninject、MVC 和 Session Scope：合理实践？

Question

我正在使用实体框架构建一个 MVC3 应用程序，其中几乎所有操作都只允许授权用户使用。因此，我经常需要引用成员实体。我已经尝试了缓存成员的不同方法，并提出了一种非常快的方法。但我想对我正在做的事情的风险/缺点提出一些建议/观点。

我已经定义了一个工厂类，用于检索在 Ninject 中“注册”的 Member 实例，这样我就可以在任何需要的地方使用它。 Ninject 绑定是“会话范围的”（我稍后会解释）。工厂方法首先检查 Session 以查看它是否包含先前创建的 Member 实例。如果 Session 没有，例程通过 EF 从底层数据库创建一个实例，将值存储在 Session 中并返回它。

因为对成员实例的一些访问是 EF 调用，所以我必须确保 EF 对象上下文也在会话范围内（我学会了针对最初在不同上下文中创建的成员实例调用 EF 例程的艰难方法效果不太好）。由于工厂和对象上下文是通过 Ninject 创建的，因此我必须为 Ninject 定义一个 Session 范围。

我找到了一个代码 sn-p 来执行 here，我可以对其进行修改以满足我的需要。但它是如此简单的 sn-p，我想知道是否有原因 Ninject（或 Ninject MVC）没有“本机”提供该功能。这让我怀疑我的所作所为是否在招惹麻烦。

我确实意识到在 Session 中存储内容有很多方面您必须围绕这些方面进行编程，其中最主要的是存储的对象可以随时“消失”（即，您总是必须有一个获得它时重新创建它的方法）。但是，虽然这增加了足够的复杂性，我不想为很多对象做这件事，但为单个 Member 对象做这件事并不是那么困难。

在任何情况下，对于会话范围的 Ninject 绑定和在 MVC 应用程序的 Session 中存储 EF 实体的建议和反馈，我们将不胜感激。

Answer 1

Ninject 本身没有这样的范围有几个原因：

• 该实施使应用程序无法扩展。虽然可以在多个 IIS 实例之间共享会话，但会话范围内的数据却不能，因为每个 IIS 实例都有自己的 Ninject 内核。
• 它将鼓励用户大规模使用它。但一般来说，除非绝对必要，否则将数据放入会话中并不是一个好主意，因为它被缓存了很长时间，并且没有机制在会话超时之前将其从内存中取出。这会很快导致内存不足的问题。出于这个原因，应该非常小心地使用会话数据。
• 会话范围数据的首选方法是将其添加到会话中，并将临时绑定添加到返回此数据或创建新实例（如果尚不可用）的方法。这样，数据将与会话一起被删除，而不是将其保留在内存中一段时间​​，直到 Ninject 释放它。此外，这种方式还支持应用程序的缩放。

您的 Ninject-wise 实现没有问题。但正如我之前所说，您必须非常小心地将数据放入会话范围。我认为您还应该考虑其他缓存数据的方法，以便在使用这种方法之前驱逐数据，例如，使用 NHibernate，我建议研究 2 级缓存。如果您仍然决定使用会话数据，更好的方法是将其放入会话中，而不是使用 Ninject 会话范围，因为它允许扩展应用程序。