我一直在分解Web应用程序的应用程序层和Web层。在应用层中，我设法将业务逻辑分离成一系列使用WCF代理公开的服务。问题是这些服务与另一个使用大型CLR对象作为其主要通信手段的传统应用程序进行通信。为了保持快速，我在第一次创建该对象时一直保留该对象的副本。现在我知道WCF可以完成会话，但会话存储是按服务进行的，而我的业务逻辑现在分成多个服务（应该是这样）。WCF服务之间的共享会话
现在的问题：
这可能不是第一次有人在服务器上有一个大的业务对象。不幸的是，我确实需要为每个用户缓存这个对象（因此会话）。
这可能是答案很明显，我只是没有看到它。请帮助！
如果您希望能够将应用分散到农场中，将事情分解为子服务似乎是个不错的主意。但是，请记住，无论何时一个对象在变化的最小值处穿过应用程序边界时，都必须将其复制到内存中。
这一切都取决于对象的大小和它拥有的数据类型。
如果你不想传递对象，因为它太大，你可能想为接收它的服务创建一个查询API。通过这种方式，您可以操作该对象，而无需执行昂贵的序列化或远程处理。
就我所了解的WCF而言，它被设计为尽可能无状态。在会话中，您可以记住服务中的一些值，但对象并不意味着超出会话范围。
因此，我认为你有麻烦。
当然，可能有一些方法可以在不知道的会话之间存储和交换对象（我使用WCF，但除了我自己需要的东西外，我对此不太了解）。
（如果有共享的服务对象之间的一种方式，它可能只会在你主持自己的服务工作。IIS托管可能回收有时为您服务）
也许你可以在一个单独服务包装这个对象。这是一个只有一个实例的服务，在调用之间不会被销毁。由于每个用户需要一个对象，因此该服务必须管理它们的列表，并且调用服务必须提供所需的认证数据（或sessionid）。不要忘记超时以摆脱不需要的对象...
创建一个facade service，它代表其他应用程序层服务托管大型CLR对象。它可以作为adapter工作，为您创建的更高级应用程序层服务提供更具体的会话标识符。 Facade可以提供会话标识符，例如GUID，应用层服务可以使用该标识与大型CLR对象重新连接。
这提供了几个优点：
你的一些应用层的可能并不需要了解的CLR对象都没有。他们只与远程门面进行通信。
“大型CLR对象”主机代表其他可以共享它的服务保留会话对象。
应用程序层现在有一个门面，通过它与传统服务对话。在您重构此旧服务时，应用层无需更改。
根据您的设置，您可能能够通过proc主机托管这个门面，这将使您寻求的保持性能提升。
我认为实例上下文共享可以帮助
保持简单。由于您已经可以访问WCF中的Session，因此您可以使用SessionID。现在：
在某处创建一个静态字典，其中Key是您的sessionId，值是您要存储的业务对象。
不是访问会话中的业务对象，而是访问sessionid并从字典的Value中获取业务对象。
（如果你愿意，你还可以使用某种类型的缓存，例如System.Web.Caching，这样你就不必手动清理字典）
但你如何保持SessionID的服务之间电话？最终，您需要使用此sessionId才能从字典中获取对象 – liorafar 2012-12-05 09:10:50