WCF service with methods to fetch data

Question

I'm planning on building a WCF service that will fetch data entities from a Sql Server database. And I'm currently struggling with best practices issues.

The thing is that there's a few different ways for a user to fetch different data. For example, customer orders can be obtained from a date range, but this date range could apply to either the date the command was processed, the deadline date or the date it's actually going to be shipped.

If client apps were directly speaking to Sql Server this would be easy enough. But now with WCF I feel I must do service changes each time I want to introduce a new way of interrogating data (new service API). This means having to take down the service, losing state, updating it and restarting it.

I could of course pass a filter string to my service methods but security wise it doesn't seem to be a good idea.

As you can probably tell by now I'm pretty green with WCF and there's probably something I'm missing. Any guidance would be much appreciated.

Answer 1

There's nothing wrong with having distinct methods in your web service. This makes the service have a very explicit contract and it should easy to use for your clients. For example, your initial service may have:

• GetDeadlineOrders
• GetProcessedOrders

If you have to add another method in the future like:

• GetExpiredOrders

Your service is forward compatable so existing client will not be effected and clients who want to use the newer functionality can do so.

The easiest way to manange this is with versioning as @BatteryBackupUnit has mentioned prior. By running different versions clients can upgrade in the future without being forced to upgrade when your service is deployed.

There is just a diffferent URL, in the past example the services could be:

• http://mywcfservice/v1 (Has processed and deadline methods)
• http://mywcfservice/v2 (Has process, deadline, and expired methods)

One just keeps N versions available and rolls off lower versions as needed giving clients plenty of advanced notice.

The other way is to design a more generic method:

• GetOrders

This method would take in another parameter/object that would have the necessary details to formulate the query. One way of implementating generic methods is to use a dictionary of name/value pairs in the contract so that it can be extended without changing the schema. This makes the service less explicit and harder to use because now the client can really pass any name/value pair in the service call and it is up to the code to parse it and build the proper query to the database.

If the service is going to change frequently, it may be better to go the generic route so the contract never changes. Bear in mind that with such a loose contract definition there could be more error requests and misunderstanding between client/service.

If there are planned releases, like every quarter, then having an defined schema with different versions will be OK and easier to use. Just version the releases and make your service forward compatible and it should be good to go.

Answer 2

No i think you're right. Of course you could also design your interface to be more flexible regarding querying. Let's just call it "design ahead". But of course this conflicts with YAGNI. So you'll need to compromise.

Another alternative would be to run the old and the new service version on different ports /URLs - thus getting rid of the downtime. You'll still have to switch over "old" clients to "new" clients at some point, but maybe at a more convenient time. Of course this also entails more SW and deployment complexity which results in higher costs.

So as long as you can live with the downtimes it's probably just the way to go.