.NET Remoting到WCF - 构建解决方案以避免循环依赖

时间:2011-07-04 20:28:27

标签: wcf projects-and-solutions circular-dependency

我正在尝试将使用.NET Remoting的现有项目转换为使用WCF。该项目的结构如下:

  • UI
  • BusinessLayer

BusinessLayer项目是一个类库,其中包含具有方法DistributedProcessor的客户端激活对象IResult Process(IJobProcessor)IJobProcessorIResult接口以及具体类都在BusinessLayer库中。 IJobProcessor的具体类反过来使用BusinessLayer中的许多类。

对于.NET Remoting,这种情况是理想的。分布式部分只是一个包含BusinessLayer并侦听特定端口的Windows服务。客户端使用Activator.GetObject()创建远程对象。

要将此转换为WCF,我意识到如果我按如下方式构建项目,则会出现循环依赖性问题:

  • UI
  • BusinessLayer - 引用WcfService
  • WcfService - 引用BusinessLayer

该服务需要对BusinessLayer的引用,以便我可以通过网络传输对象。 BusinessLayer需要对WcfService的引用,以便它可以在WcfService上调用IResult Process(IJobProcessor)方法。

我可以将接口IResultIJobProcessor移出到单独的项目BusinessLayerDistributed中,例如:

  • UI
  • BusinessLayer - 引用BusinessLayerDistributed
  • BusinessLayerDistributed
  • WcfService - 引用BusinessLayer,BusinessLayerDistributed

我的问题是:如果所有这些接口的具体类仍在BusinessLayer中,那么IResultIJobProcessor对象在转移到服务时是否可以作为其具体类进行适当的水合?用WCF做这个有什么技巧吗?

1 个答案:

答案 0 :(得分:0)

为什么业务层必须调用服务层中的任何内容?业务层不应该具有关于服务外观层的任何知识,也从客户端调用正常服务 - 从不从业务层调用,因为这在服务体系结构中没有意义。

唯一的例外是双工(双向)通信,但即使使用这种架构,您仍然不会在程序集中使用循环依赖。有一些模式可以避免这种情况 - 例如,业务层可以有事件,服务层可以订阅它们。订阅将在服务服务层中完成,该服务层参考业务层。如果您不喜欢事件,可以使用Observer GoF模式。

从业务逻辑调用服务层的另一个有效方案是完全面向服务的体系结构,但在这种情况下,每个“服务”都将拥有自己的服务程序集和业务逻辑程序集,您将在它们之间进行交叉调用。