- PerCall.
- 为每次调用创建新的服务对象.
- 内存使用量最小,增加整体的吞吐量.
- 状态不保存，服务实例及时释放。
- 单例的状态没有办法保存.所以应使用数据库或者文件或者全局变量来保存服务实例的状态.如果单调服务真的与状态无关，就根本不需要单调激活模式。准确地讲，正是因为状态，特别是代价昂贵的状态，才需要使用单调模式.
- 不会有并发性问题。
- 服务的利用率最高，只有在需要时才会有服务实例的创建。不会有闲置的服务对象。
- 在实例销毁时,不会断开与客户端的连接.在事务编程(保证实例状态的同步)与队列服务中(单调服务能够建立服务实例与离散队列消息之间的简单映射)最好.
- 采用单调服务的根本原因，是在于单调激活模式的本质就在于能够适时释放实例所持有的昂贵资源，这里的资源大体上讲就是一种状态。如果不需要维护状态，则意味着性能上没有太大的损耗，我们就没有必要采用单调激活模式了，毕竟频繁地创建与销毁实例，仍然会对性能造成一定的影响.
- 但是当服务对象的创建需要很大开销时，该模式会使得整体的吞吐量减少,此时不应再使用它.
- 业务逻辑层和数据访问层相互独立，应考虑共享。
- 对于每次都要使用的资源放入Cache,但会产生并发行问题，要上锁，对于耗时的操作，也放入Cache.
- Session.
- WCF有4种会话：传输，可靠性，安全，应用程序。
- 会话应保证是可靠的,实现了会话的服务的终结点都应该使用支持可靠会话传输的绑顶类型.
- Session是由客户端发起的，这样使得只有在有请求时才创建，更高效，且保证了消息的有序。
- 但是ASP.NET的会话由服务器发起。
- 会出现多客户时的并发问题，应对临界资源进行加锁,但是这样减少了服务的吞吐量。
- 由于维护状态，所以内存开销比较大.
- 业务逻辑的组件是完全独立的，即无状态。状态的保存是发生在Session层。当想在业务逻辑层保持状态时，应该把状态信息保存到服务层,即Session层。
- 服务与状态紧密相连。SessionMode: Allowed：如果当前使用的Binding支持Session,就使用Session.如果不支持，就不会使用。NotAllowed：无论怎样。都不使用Session功能。推荐。使得设置明确。有确定行为。Required:当Binding不支持Session时。会使得服务失败。推荐。
- 绑定和实例模型的对应依赖于SessionID.任何形式的会话都会生成会话信道，ID用来将消息和信道绑定起来.
- 通常，一旦客户端关闭了代理，会话就会终止。但是，客户端也可以强行终止会话，也可能因为通信故障而终止会话。每个会话还包含了一个空闲超时值，默认为10分钟。会话如果是因为空闲超时的原因被终止，那么当客户端试图使用它的代理时，会获得一个CommunicationObjectFaultedException异常。在绑定中通过配置不同的值，可以为客户端和服务配置不同的超时值, 以短的超时值为准。支持可靠传输层会话的绑定提供了ReliableSession属性，类型为ReliableSession或者OptionalReliableSession。ReliableSession类定义了InactivityTimeout属性，属于TimeSpan类型，通过它可以配置一个新的空闲超时值.
- 实例停用
- 仅对会话实例模式有效.
- 会话除了关联客户端信息外,还需要关联托管了服务的上下文.上下文会随着会话的开启关闭而被创建和销毁.默认上下文的生命周期与服务实例一样.为了优化,可以分离两者.可以独立的停用实例,或者有不含实例的上下文.
- 通过服务契约的ReleaseInstanceMode= None/ BeforeCall/ AfterCall/ BeforeAndAfterCall.
- 也可以通过编程方式在服务的操作中显式地完成对实例的停止。方法是利用InstanceContext的ReleaseServiceInstance()方法,可以混合使用这两种方法.
- 单件.
- 加锁后，只有一个请求能被处理，造成吞吐量的减少。只有当不会有临界资源时才会使用。且会带来死锁的危险。
- 也可以有状态(使用SessionID).
- PerCall高可扩展性和高吞吐量；Session应注意Session带来的开销和潜在的超时可能性；一般不使用单件模式。只有当多台客户端共享一个功能时.