WCF service contract design. Is a use case controller appropriate?

Question

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...

1. GetComplaintTypes
2. GetCustomerTypes
3. GetAreaDetails
4. 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.

Answer 1

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.

Answer 2

I think you first have to determine where exactly the performance problem is. Is it really true that IIS can't handle the amount of requests you are sending to it? Or is each individual request taking too long because the database can't serve up your data and does it just look like IIS can't handle the pressure because of this.

I'm not sure there's a real difference between the two following scenario's:

• Small requests that each execute a database select statement.
• One large request that executes a lot of database select statements.

Of course I'm not sure about your specific situation but where performance is concerned, it's always wise to know beforehand exactly why you're optimizing.

Answer 3

WCF service on the top of business logic should expose facade of high level business operations not low level CRUD operations. CRUD operation services are for exposing data (like WCF data services).

Answer 4

Here is my take on it all. The answer is as always, it depends.

Here are some practical examples of how to build a SOA using WCF.

I would suggest you read articles by Thomas Erl and Roger Sessions, this will give you a firm handle on what SOA is all about.

Building a SOA

SOA Design Pattern

Achieving integrity in a SOA

Why your SOA should be like a VW Beetle

SOA explained for your boss

Answer 5

The simplest approach for exposing data from the DB using a CRUD pattern with WCF is to use WCF Data Services. You don't actually do not develop anything on the server side more than the model you want to expose, which it could be also automatically inferred from an EF model if you are using that for getting access to the database.

Pablo.