Asp.net MVC5中的对象创建生命周期

Question

  

在Asp.net MVC中根据请求创建控制器，这是事实。

我的问题是： 创建Web应用程序中使用的公共对象（Logger，Localizer，Configurator）的最佳实践是什么，据我所知，可能的方法是：

1. 按请求创建对象，然后在请求结束时将其丢弃。
2. 在用户会话开始时创建对象，然后在会话结束时将其丢弃。
3. 仅为整个应用程序创建一个对象，并在应用程序关闭时将其处置。

Answer 1

完全取决于使用这些组件的范围及其依赖关系，详细说明：

记录器

记录器通常在应用程序的整个生命周期内都存在，并且可以在整个应用程序（范围）中使用，记录器不关心request或{ {1}}（依赖项）。 最佳终身范围：应用。

LogSource / LogContext

与logger不同， LogSource / LogContext 是与给定上下文（范围）一起使用的上下文对象，这些对象知道它们的上下文（{{1 } / controller）（依赖项）。 最佳终身范围：控制器 / 请求。

航向

Localizer 与其他组件相比不那么明确。例如，它使用应用程序范围（控制器，视图等）（范围）。但至于其依赖关系，问题是特定于实现的，您的controller可能需要request对象进行构建，否则可能不需要。在不需要的情况下，该组件没有依赖关系， Application 范围将适合。

另一方面，如果需要文化，那么它就是该组件的依赖。现在将其范围扩展到用户会话是合乎逻辑的，但这是性能和依赖性细节的概念发挥作用的地方。如果将localizer范围限定为用户会话，则每个用户在服务器响应之前将有CultureInfo个时间来读取本地化文件。此外，依赖关系不 localizer但是用户的x，而可能的user session是无限的，可能的支持的本地人几乎是无限的。记住这一点，然后您可以创建一个culture，其中包含每个受支持的本地（可能是不支持的本地回退本地），作用于应用程序，可以提供服务user session范围为localization pool。

总结 - 您可以将范围依赖性逻辑应用于任何组件，但是当我们使用localizers种子时，始终最好理解组件以及将该组件范围限定到特定范围的含义。

Answer 2

这实际上取决于两件事：

1. 这些常见对象的实现 - 例如线程安全。例如，如果您的记录器具有单个生命周期并且它具有一些静态属性（例如级别或名称），那么通过在一个请求中修改它将影响其他人（这很可能是不需要的行为）。
2. 这些对象的目的（用法） - 假设您有一个LoggerManager或Configurator或某种Factory object，应该只在应用程序启动时初始化一次，然后它用于创建（检索）其他对象（例如IoC容器），然后将它设为单例（有时绝对需要）是有意义的。

根据我的经验，大多数对象都有transient或per-request生命周期。关于单例（整个应用程序的一个对象） - 通常很清楚何时使用它们。我认为一个上帝示例是LoggerManager，用于根据某些静态配置创建Logger实例或Configurator（如您所说）在应用程序启动时初始化并解析一些配置文件。我对单身人士的经验法则是：

• 他们必须是线程安全的

• 他们不经常改变

• 他们要么持有一些适用于所有线程/请求/用户等的共享数据

• 它们是重物 - 如果它们重量很轻，你可以每次创建一个新物体（瞬态生命周期），并且很可能你没有注意到性能的任何差异。

  < / LI>

关于会话 - 对我来说它更像是一个缓存，所以大多数时候它都拥有一些用户相关的数据