How Granular Should My Services Be?
This is a) a very common question, and b) very hard to provide absolute prescriptive guidance on.
In short, this is where the “art” of architecture & design comes into play!
How granular you make your service largely depends on how you’ll use it. Always bear in mind, however, that you should avoid traversing the wire as much as possible. Therefore, if you design your service so that you have to call 10 actions in order to refresh a customer data page, then you’ll likely experience severe perf and scale issues. A better approach is to call one GetCustomerData(…) method once and build the customer data page from the returned data.
“Ah, but my service has to be used by many callers – some require a great deal of customer data, but many only need the name of the customer”. In which case, your service should expose BOTH fine-grained and large-grained actions:
[ServiceContract]
class Customer
{
// Only returns customer name.
[OperationContract]
string GetCustomerName(Uuid customerID)
{ /* implementation */ }
// Only returns customer address.
[OperationContract]
CustomerAddress GetCustomerAddress(Uuid customerID)
{ /* implementation */ }
// Large-grained customer record retrieval.
[OperationContract]
CustomerRecord GetCustomer(Uuid customerID)
{ /* implementation */ }
// Large-grained customer record update – note that this is one-way!!
[OperationContract(IsoneWay=true)]
Void UpdateCustomer(Uuid customerID, CustomerRecord customerRec)
{ /* implementation */ }
}
Note that when using newer technologies such as WCF (formerly “Indigo”), anything that returns a void could be marked as OneWay. This means that the sender doesn’t have to hang around and wait for the service to complete processing the action. This can be a massive scalability booster! :)
