asp.net-mvc - Ninject、MVC 和 session 范围 : Reasonable Practice?

Question

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

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

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

我找到了一个代码片段 here我可以对其进行修改以满足我的需要。但这是一个如此简单的片段，我想知道是否有原因 Ninject(或 Ninject MVC)没有“ native ”提供该功能。这让我想知道我是否正在通过我正在做的事情来找麻烦。

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

无论如何，对于 session 范围的 Ninject 绑定(bind)和在 MVC 应用程序的 Session 中存储 EF 实体的建议和反馈将不胜感激。

Answer 1

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

该实现使得无法扩展应用程序。虽然可以在多个 IIS 实例之间共享 session ，但 session 范围内的数据却不能，因为每个 IIS 实例都有自己的 Ninject 内核。

它将鼓励用户大规模使用它。但通常除非绝对必要，否则将数据放入 session 中并不是一个好主意，因为它被缓存了很长时间，并且没有机制在 session 超时之前将其从内存中取出。这会很快导致内存不足的问题。出于这个原因，应该非常小心地使用 session 数据。

session 范围数据的首选方法是将其添加到 session 中，并将 transient 绑定(bind)添加到返回此数据或创建新实例(如果尚不可用)的方法。这样，数据将与 session 一起被删除，而不是将其保留在内存中一段时间​​，直到 Ninject 释放它。此外，以这种方式支持应用程序的缩放。

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