Is my mediator layer a sensible way to manage this scenario using the Single Responsibility Principle?

Question

I'm not sure how to start to explain my question, but here goes.

We have just finished an MVC application that hits 2 WCF services. But there has been a bit of a disagreement between those who worked on the project and some who haven't over the design used. What we have is two WCF services, one on each site (site specific data) and another at head office (data shared/common between all sites). Normally we would have two apps, one for site and another for head office. In this case I decided from a UX point of view that it would be better to have it look like one app from the users point of view so they would not need know two urls. Basically, the user does not know if they are hitting site or head office.

Now comes the design decision that has caused the disagreements. The MVC App has controllers that need to hit either a site wcf service or a head office WCF service. So to prevent the need of the controllers needing to be aware of the two WCF communications layers and converting the WCF results into a model the controllers could use, I created a layer in between the controllers and WCF Proxies. Which accepts a request from a controller, then calls the appropriate site or central WCF proxy call, then if needed, convert the WCF result into a model that the controller can use.

This layer, I called a Mediator, but after much discussion, I am of the opinion that it is not the correct description for it. Anyway, the reason for this layer is when tring to keep to the SOILD object oriented principles, in particular the Single Responsibility Principal. The controllers responsibility is to handle client requests and return a view/result. It should not need to know or maintain a WCF proxy and convert its result. (It could go directly to a database instead of a WCF call but the controller shouldn't be responsible or even aware of that because it is responsible for the view) The same goes for the WCF proxy, it should not know what is consuming its result and that the WCF data contract should be converted into a model specific for each controller. The mediator layer in between is what decides which WCF service and method to call and then either via a extension method or a specific handler converts the result to a model the controller can use. (sometimes it may take several wcf calls to create the model).

Controller1 -> Mediator -> HeadOfficeWCFProxy
Controller2 -> Mediator -> SiteWCFProxy

• So the controller asks for data (not knowing where it comes from)
• The mediator converts and passes the request to the appropriate WCF Proxy(s)
• The WCF Proxy(s) make the calls across the wire and return the results.
• The mediator then converts the result(s) into a model (if needed) via an extension method and returns it to the controller.
• The controller renders the view using said model.

Now what I described here was just on the MVC side. I have a similar setup on the WCF service side but the mediators benefit is clearer.

On the head office WCF service

WCFListener -> Mediator -> DataLayer (LinqToSQL)
                        -> SiteSyncHandler (sends change to all sites asyncronously)
                        -> ThirdPartyContentManagementHandler (via web service)

Now the devs that have worked on the project, like the separation of concerns alot as it is very clear where everything belongs and keeps code to a minimum in each layer. But the down side in the MVC app is for a lot of the calls the mediator just makes a single WCF call and doesn't even need to convert the result (most of the time the data contract is fine for use as a model) resulting in a fair amount of one liner method boiler plate code. The mediator doesn't really add much in that scenario except to keep things consistent across controllers. Some devs that haven't worked on the project, insist that there is no need at all for the Mediator layer and that it could be all handled by the controllers themselves. Which means maintaining the appropriate WCF Proxy in each controller. This in my mind violates the Single Responsibility principle. To which they argue that SOLID is more like a set of guidelines, and not to be blindly followed. Which while I kinda agree with that statement its also not to be blindly ignored.

I have conceded that the term mediator is not really appropriate (perhaps director or relay), but I still think the basic design is valid, and would use it again. The same can be said for those who have worked on the project. I would like to know what other people think. Is there a better solution or have I "over complicated it". (I still don't agree that is is complicated, its a very simple concept and easy to maintain)