我正在尝试跨单独的进程“共享”.net 对象。我有一种类型的进程，它是一个操作一组域实体的 Web 服务。另一种类型的进程是窗口服务，它对同一组对象进行一些自动批处理。
除了将数据库作为两种类型的进程读取/写入对象的共享空间的典型解决方案之外，让这些不同进程查看和处理相同对象的更好、更分布式的架构可能是什么？
我考虑过使用分布式缓存作为对象的共享存储，但这并不完全支持对象及其关系。插入分布式缓存的对象图被展平，对象最终存储在多个断开连接的副本中。
“消息总线”是否是正确的方式，让进程相互发送对象的更新副本？
还是有其他完全可以考虑的解决方案？
我建议使用 WCF 服务。对于本地使用（从 Windows 服务调用），您可以使用 netNamedPipeBinding。这使您可以在将来物理上分离这两个过程。
您将需要决定您的两个服务中的哪一个，或者可能是第三个，尚未成文的服务，是您的域对象的权威来源。
由权威源公开的远程处理或基于 WCF 的服务集应为您的对象图提供中心位置。但是，我认为您只是在为对象创建分布式缓存。
您是否考虑过Velocity 项目？
在我们的项目中，我们使用 ScaleOut StateServer（一种商业产品 - www.scaleoutsoftware.com）在整个服务器场中完成对象的分布式缓存/复制，以实现类似目的。这非常有效，尽管使用对象确实会产生（反）序列化成本，因此在许多情况下，我们将存储的内容简化为可能的字符串值。
我们还没有完全评估 Velocity 项目，因为我们的使用在此之前就已经开始了，而且我们现在没有时间或令人信服的理由来考虑转换，但如果你现在才开始，这显然需要进行一些调查。
编辑：我确实错过了关于这个问题的重要部分——对象引用的扁平化。这可能会使事情过于复杂或有其他缺点，但是如果您采用更紧密地模拟分布式缓存中的数据库存储的方法（保持它存储每个不同对象实体的单个副本，并使用更松散的引用来链接那些实体在一起）？
示例：您有一个类“Group”，它具有“Leader”属性和“Members”集合，所有这些都包含作为“Person”类实例的对象。您必须使用自定义序列化来完成它，没有什么能神奇地解决并发/脏更新问题，但想法是您放入分布式缓存的内容实际上也是所有单独的“Person”实例作为“组”实例本身的浅拷贝。该浅拷贝将序列化正常的“组”属性（名称等），以及其中包含的每个“人员”引用的唯一标识符（如原始数据库 ID、GUID、唯一用户名或任何合适的），而不是Person 对象本身。所以你会有一个'LeaderID' 而不是领导者，成员集合将序列化为成员 ID 的列表。引用的每个 Person 也存储为单独的对象；这就是并发技巧发挥作用的地方。
在反序列化（或访问时，取决于使用模式）时，Group 浅拷贝将遵循所有 Person ID 引用，并使用单独存储在分布式缓存中的真实 Person 对象重新水合这些引用。您需要实现锁定机制，以确保对可以在许多不同组之间共享的这些对象的更新是安全的。您还需要版本控制机制和“脏检查”，以重新读取/获取在分布式缓存中对 Person 对象所做的任何更改。
它看起来确实很复杂，但这是我在不知道您的用例细节的情况下能想到的最通用的方法。