First off, apologies if this question has been asked before but I couldn’t find anything that answers this directly.
Here’s my problem. I’ve inherited a product which has been designed to be so flexible that populating pretty much every combobox and textblock on the (silverlight) form requires a service request. Some of the screens take upward of 15 separate requests just to populate!
Now I’ve worked with WCF web services on a number of occasions and having service contracts split into small discrete operations has never been too much of a hit,..sadly this is not the case for this project. So it left me wondering…
There are no plans to expose the service outside of our own walls. There are no plans to write another client for this particular service. So couldn’t I just write a ‘use case controller’ at the service end? So, in a ‘create complaint’ screen, instead of having a list of requests like…
- GetComplaintTypes
- GetCustomerTypes
- GetAreaDetails
- And so on…
to populate the form I would just have a single operation contract called ‘GetCreateComplaintData’. It seems crazy to have so many operations exposed in such granularity when there’s only one client which then has to aggregate and synchronise all these requests into something meaningful. Why not expose something meaningful in the first place?
More to the point, if you don’t intend on exposing the service API to third parties isn’t this a better strategy than exposing CRUD ops for tables in the DB?
All help and opinions are appreciated.
Thanks in advance.
I think your idea is quite OK.
As an in-between way, you may also think about an approach where you batch several WCF requests into one. This approach and how to program it is described over here.