使用Global.asax的利弊是什么？
让我们收集一些技巧，以评估对global.asax的适当使用。
解决方案
我以前曾用它来捕获应用程序级别的错误，并在用户会话期满时执行一些操作。
我也倾向于使用它来提供从web.config中读取值的静态属性。
我认为这样的事情还可以，尽管我不会在那儿投入太多。
Global.asax可以从我们自己的继承httpapplication的类继承。给我们更多选择，并将我们可能在全局中拥有的大部分代码放入类库中。
编辑：在单独的类库中拥有HttpApplication类(global.asax父级)也可以提高可重用性。尽管我同意使用HttpModules更适合于许多任务，但是对于一个较干净的代码而言，它仍然具有许多用途。
我还没有真正使用过Global.asax。我一直在经典ASP中使用它，但是它主要与某些配置有关，例如数据库连接字符串等。 .net中的配置使许多这些事情变得更加容易。
但是，如果要实现应用程序和会话级别的事件，则这是我们需要去的地方。
这是获取会话启动甚至请求启动的好地方。其他人提到了错误处理方面，尽管要小心非asp.net线程(例如，线程池或者自定义线程)抛出的异常，因为它们会绕过global.asax处理程序。就我个人而言，我总是有一个，我认为它只是管道的一部分。
- 初始化ASP.NET MVC。 :)
- 自定义用户身份验证。
- 依赖注入，就像扩展Ninject HttpApplication一样。
如果会话和应用程序初始化代码非常小且特定于应用程序，则使用起来很简单。如果我们想重用代码，例如设置URL重写，重定向或者身份验证的规则，则使用HttpModule更为有用。 HttpModule可以覆盖Global.asax文件可以实现的所有功能。也可以使用.config轻松删除和添加它们。
我曾经使用Global.asax进行错误处理等操作，但是，此后我开始使用HttpModules替换它，因为我可以在不编辑global.asax的情况下将其从一个项目复制到另一个项目。
它是烈性酒，请注意不要喝太多，这样我们会没事的。
我将其用于全局错误处理，并在mvc中设置路由。但是，我们不想在其中编写全局page_init代码。
如果我们坚持应用程序级别的事件，并使大多数逻辑实际存在于在这些事件期间被调用的类中，那么使用全局构造将毫无问题。
与HttpModule相比，使用Global.asax的缺点：我们将很想编写难以重用的代码，因为它与特定的应用程序过于相关。
Global.asax中的Session_Start事件是初始化会话变量的理想场所。
