有状态组件与无状态组件

有状态组件还是无状态组件

在讨论状态使用的选择之前，让我们从服务组件开始。如前面所述，服务组件可以有状态也可以没有。无状态提供了更好的可伸缩性，因为调用之后不会继续占用服务器资源。

要创建一个无状态组件，你可以使用[JustInTimeActivation]特性，同时在方法上应用[AutoComplete]特性。

支持事务的组件总是无状态的。这样它们可以在事务正在运行时保持状态，而在事务完成或者中止后，这些组件都会被终止，这样状态也就随之丢之了。

要创建有状态的组件，你不用做任何其他特别的工作，只是不要应用[JustInTimeActivation]即可。

（译注：应用了[Transaction]特性之后，即时激活（JustInTimeActivation）会自动启用。所以无论是否应用了[JustInTimeActivation]特性，只要应用了[Transaction]特性，组件都是无状态的。）

如果你使用.NET Remoting来访问服务组件，那么组件是否有状态应该在.NET Remoting的配置文件中定义。客户端激活的（client-activated）对象是有状态的，而well-known对象是无状态的。

使用有状态组件，你将得到以下这些特性：

●   有状态组件不是持久的。在组件终止时状态会被丢失。支持事务的组件在事务结束后会失去状态。

●   如果状态经常改变，有状态组建可能是个好的选择。有状态组建允许极高速的状态改变，只要没有垮越进程边界——也就是说，如果调用者运行于同一个进程（如果服务组件被配置为类库激活，或者调用者是服务组件本身）。如果调用者在另一个机器中，那么访问状态信息需要更多的时间。

●   有状态组件的生存周期受制于那些对它的引用。只要存在一个引用，它就存活着，状态就会保持着。如果你使用.NET Remoting来访问服务组件，那么引用的保持受一个租约机制的控制。

●   有状态组件，与对它有引用的每个调用者都是相关联的。这种关联可以是与一个客户端应用程序；或者，如果引用被传递的话，那么这种关联也可以是与多个客户端应用程序。如果引用是共享的，需要注意同步问题。如果一个组件为多个客户端所共享，也许最好是设置同步选项[NotSupported]，然后提供自定义的同步机制。这样，多个客户端就能并发访问该组件。当然，这么做的缺点是，你需要自己处理同步问题。

●   状态数据的大小受进程的制约。在32位的操作系统上，你只有2GB的用户空间可用。一个进程内的所有对象的状态都受这个上限的制约，不过，在远未达到这个上限之前，你得考虑下是否应该把状态数据放在数据库里面。

●   在使用组件的负载均衡（load-balancing）服务时，应该不使用有状态组件。使用组件的负载均衡服务时，对象分布在多个系统中以增强可伸缩性。由于状态不能在多个系统中共享，所以必须保证只访问相同系统上的有状态组件。