WCF Separation of Problems VS DRY

Question

I am writing a WCF service application where I have isolated WCF classes in my own "Presentation Layer" (due to lack of a better term). Then under this, I have an application layer that organizes domain objects.

I like the fact that none of the WCF technologies has leaked to the application layer, so I can easily exchange it for something like the Web API (which I reviewed). My concern, however, is that it seems to break the rules without repeating itself. The WCF layer has essentially become a proxy layer that simply transfers calls to the application layer, supporting the same signatures.

For example:

public void Method(string arg)
{
   _appService.Method(arg);
}

Is this a murder? Should I just move the logic to WCF classes?

Answer 1

You must be careful when implementing the DRY principle in service-oriented applications. Often a service creates its own restricted context where you want to create code regardless of the business logic in other services. An exception to this rule is the "Utility" code, which takes into account cross-cutting issues throughout the entire vertical slice.

As for the specific example that you give, you have separated your logic from how it is placed. This does not violate DRY, as the context of the code is different.

Answer 2

, . , , . , .