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