我一直致力于拆分 Web 应用程序的应用层和 Web 层。在应用层中，我设法将业务逻辑分离成一堆使用 WCF 代理公开的服务。问题是这些服务与另一个使用大型 CLR 对象作为其主要通信方式的旧应用程序进行通信。为了保持快速，我在第一次创建该对象后在会话中保留了该对象的副本。现在我知道 WCF 可以进行会话，但是会话存储是每个服务的，而我的业务逻辑现在被拆分为多个服务（应该如此）。
现在问题：
这可能不是某人第一次在服务器上拥有大型业务对象。对我来说不幸的是，我确实需要为每个用户缓存这个对象（因此是会话）。
可能答案很明显，而我只是没有看到。请帮忙！
【问题讨论】：
标签： wcf
我认为实例上下文共享会有所帮助
【讨论】：
据我了解 WCF，它被设计为尽可能无状态。在会话中，您可以记住服务中的一些值，但对象并不意味着存在于会话范围之外。
因此，我认为你有麻烦了。
当然，可能有一些方法可以在我不知道的会话之间存储和交换对象（我使用 WCF，但我不太了解它，除了我自己需要的）。
（如果有办法在服务之间共享对象，它可能只适用于您自己托管的服务。IIS 托管有时可能会回收您的服务）
【讨论】：
也许您可以将此对象包装在单例服务中。这是一个只有一个实例的服务，在调用之间不会被销毁。因为您需要为每个用户创建一个对象，所以该服务必须管理它们的列表，并且调用服务必须提供所需的身份验证数据（或 sessionid）。不要忘记超时以摆脱不需要的对象...
【讨论】：
创建一个facade service，它代表其他应用层服务托管大型 CLR 对象。它可以作为adapter 工作，允许将更具体的会话标识符用于您创建的更高级的应用层服务。外观可以提供会话标识符，例如 GUID，您的应用层服务可以使用它来重新连接大型 CLR 对象。
这提供了一些优势：
您的某些应用程序层可能根本不需要了解 CLR 对象。它们只与远程门面通信。
“大型 CLR 对象”主机代表现在可以共享会话对象的其他服务保留会话对象。
应用程序层现在有一个外观，它们通过它与旧服务进行通信。在您努力重构此旧服务时，应用层不必更改。
根据您的设置，您可以通过 in proc 托管来托管外观，这将提高您正在寻求的保留性能。
【讨论】：
如果您希望能够将应用程序分散到整个农场，将事物分解为子服务似乎是一个好主意。但是，重要的是要记住，每当一个对象至少跨越 appdomain 边界时，它都必须被复制到内存中。
这完全取决于对象有多大以及它拥有什么样的数据。
如果您不想传递对象，因为它太大了，您可能需要为接收它的服务创建一个查询 API。通过这种方式，您可以操作该对象，而无需进行昂贵的序列化或远程处理。
【讨论】：
保持简单。由于您已经可以访问 WCF 中的 Session，因此您可以从那里使用 SessionID。现在：
在某处创建一个静态字典，其中 Key 是您的 sessionId，value 是您要存储的业务对象。
无需访问会话中的业务对象，只需访问 sessionid 并从字典的值中获取业务对象。
（如果您愿意，也可以使用某种类型的缓存，例如 System.Web.Caching，这样您就不必手动清理字典）
【讨论】：