AppDomain的好例子

可能最常见的方法是从不受信任的方加载包含插件代码的程序集。代码在自己的AppDomain中运行,隔离应用程序。

此外,不可能卸载特定程序集,但可以卸载AppDomain。

在完整的总结中,ChrisBrumme有一篇关于这方面的大量博客:

http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

AppDomain的另一个好处(如您在问题中提到的)是,您加载到其中的代码可以使用不同的安全权限运行。例如,我编写了一个动态加载DLL的应用程序。我是一名教师,这些是我正在加载的学生DLL。我不想让一些不满的学生清除我的硬盘或损坏我的注册表,所以我将代码从他们的DLL加载到一个单独的AppDomain,它没有文件IO权限或注册表编辑权限,甚至没有显示新窗口的权限(它实际上只有执行权限)。

我认为拥有AppDomain的主要动机是,CLR设计人员希望有一种隔离托管代码的方法,而不会导致多个Windows进程的性能开销。如果clr最初是在Unix上实现的(在Unix上创建多个进程的成本要低得多),那么AppDomain可能永远不会被发明出来。

此外,尽管第三方应用程序中的托管插件架构肯定是AppDomain的良好使用,但它们存在的更大原因是对于像SQL Server 2005和ASP.NET这样的知名主机。例如,ASP.NET宿主提供程序可以提供一个共享宿主解决方案,该解决方案支持来自多个客户的多个站点,所有站点都位于同一个框中,在单个Windows进程下运行。

应用程序域对于应用程序的稳定性非常好。

通过让您的应用程序由一个中央进程组成,然后在单独的AppDomain中生成“功能”,您可以防止全局崩溃(如果其中一个出现错误)。

如果创建允许第三方插件的应用程序,则可以将这些插件加载到单独的AppDomain中,这样主应用程序就不会受到未知代码的影响。

ASP.NET还为单个工作进程中的每个Web应用程序使用单独的AppDomain。

据我所知,AppDomain的设计允许宿主实体(OS、DB、服务器等)自由地在单个CLR实例或每个程序中运行多个应用程序。因此,这是主机而不是应用程序开发人员的问题。

这与Java相比,在Java中,每个应用程序总是有1个JVM,常常导致JVM与重复资源并排运行的许多实例。

我看到2或3个用于创建单独应用程序域的主要用例:

1) 像隔离这样的过程,资源利用率和开销都很低。例如,这就是ASP.NET所做的-它在单独的应用程序域中托管每个网站。如果它在单个应用程序域中使用不同的线程,那么不同网站的代码可能会相互干扰。如果它在不同的进程中托管不同的网站,那么它将占用大量资源,而且与进程内通信相比,进程间通信相对困难。

2) 在具有特定安全权限的单独应用程序域中执行不受信任的代码(这实际上与第一个原因有关)。正如人们所说,您可以将第三方插件或不受信任的DLL加载到单独的应用程序域中。

3) 能够卸载程序集以减少不必要的内存使用。不幸的是,无法从应用程序域卸载程序集。因此,如果将一些大型程序集加载到主应用程序域中,那么在不再需要该程序集之后释放相应内存的唯一方法就是关闭应用程序。在单独的应用程序域中加载程序集,并在不再需要这些程序集时卸载该应用程序域,是解决此问题的方法。