We have a defined service layer hosted in WCF. We are now building a website that will need to use the services functionality. The website is being written in ASP.NET MVC 4 and I’m trying to decide how to reference the WCF service from the MVC app. It’s a large complex website and it will be changing on a weekly basis.
My first reaction is to abstract out the service references (About 7 services on this one WCF host) and create a service ref facade library with which the website interacts.
But, I don’t know exactly how to use the service facade in MVC. I’m starting to think the Models will be responsible for it because when the controller gets a model, that model should call the service (if needed) and return what the controller asked. I’m trying to avoid having the MVC app know details of the service references. So, I could have a model factory that creates whatever model the controllers need and they can use the service facade to accomplish it.
Is this a good plan, or am I off track?
The service facade is the way to go — it will make it much easier to managed and test in the long term. You can build the service facade as an entirely separate library in fact so you can use the facade in other apps without much to do.
Insofar as were to drop it, keep in mind that MVC is really a UI pattern, what happens below the waterline is really beyond it’s concern. So have your controllers reference the service facade and pull out models to send to the UI and don’t get hung up on what is a model vs what is a controller.
1
I would not mix the DTO models you use towards the WCF service with the models you use towards the MVC client. You’ll run into mismatches quickly.
Use the controllers to mediate between the two. It’s OK to invoke directly on service references from controllers, unless it’s hard to work with and a facade will improve things.
(View)Models typically should not do (or ‘call’) anything apart from providing data to a view. The controller pull it’s data out to setup a DTO and invoke an appropriate service method.