4

I'm writing a WCF service application where I have isolated the WCF classes into their own "Presentation Layer" (For lack of a better term). Then underneath that, I have an application layer that orchestrates the domain objects.

I like the fact that none of the WCF technology has leaked into the application layer so I can easily swap it for something like Web API (Which I've considered). My concern is, however, that it seems to break the don't repeat yourself rule. The WCF layer has essentially become a "Proxy" layer that just hands off calls to the application layer, maintaining the same signatures.

For example:

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

Is this over kill? Should I just move the logic up into the WCF classes?

mega6382
  • 9,211
  • 17
  • 48
  • 69
Chris
  • 257
  • 2
  • 14

2 Answers2

3

You have to be careful when implementing the DRY principle across service orientated applications. Often, a service forms it's own Bounded Context, where you will want to be able to evolve code independently of business logic in other services. The exception to this rule is "Utility" code that addresses cross-cutting concerns throughout a vertical slice.

With respect to the specific example you give - you have decoupled your logic from how it is hosted. This does not violate DRY, since the context of the code is different.

Lawrence
  • 3,287
  • 19
  • 32
1

I don't see any problems with what you've done. As the old saying goes, you can never go wrong with adding another layer of abstraction. As you've said, it makes it easy to swap it for another implementation.

gleng
  • 6,185
  • 4
  • 21
  • 35