.NET Remoting to WCF - Structuring solution to avoid circular dependency

I'm trying to convert an existing project that uses .NET Remoting to use WCF. The structure of the project is as follows:

• UI
• BusinessLayer

The BusinessLayer project is a class library that contains the Client-Activated Object DistributedProcessor which has the method IResult Process(IJobProcessor). The IJobProcessor and IResult interfaces and concrete classes are all within the BusinessLayer library. The concrete classes of IJobProcessor in turn use many, many classes within BusinessLayer.

For .NET Remoting this situation is ideal. The distributed part is a just a Windows service that contains BusinessLayer and listens on a specific port. The client side creates the remote object using Activator.GetObject().

To convert this to WCF I realized I have a circular dependency issue if I structure the project as follows:

• UI
• BusinessLayer - references WcfService
• WcfService - references BusinessLayer

The service needs a reference to BusinessLayer so that I can transfer the objects over the wire. The BusinessLayer n开发者_运维知识库eeds a reference to the WcfService so that it can call the IResult Process(IJobProcessor) method on the WcfService.

Can I move the interfaces IResult and IJobProcessor out into a separate project BusinessLayerDistributed, such as:

• UI
• BusinessLayer - references BusinessLayerDistributed
• BusinessLayerDistributed
• WcfService - references BusinessLayer, BusinessLayerDistributed

My question is: If the concrete classes for all these interfaces are still in BusinessLayer, will the IResult and IJobProcessor objects be properly hydrated as their concrete class when transferred to the service? Is there any trick to doing this with WCF?

Why does business layer have to call anything in service layer? Business layer should not have any knowledge about service facade layer also normal services are called from the client - never from the business layer because that doesn't make sense in service architecture.

The only exception can be duplex (bi-directional) communication but even with such architecture you will still not use circular dependency in assemblies. There are patterns to avoid that - for example business layer can have events and service layer can subscribe to them. Subscription will be done in service service layer which has reference to business layer. If you don't like events you can use Observer GoF pattern.

Another valid scenario for calling service layer from business logic is full service oriented architecture but in such case each "service" will have its own service assembly and business logic assembly you will do cross calls among them.