Building n-Tier apps can be difficult. Instead of a single monolithic application that can easily hide its imperfections, a client-server model traditionally means making an API, choosing a transport, and sticking to it.

It’s like marriage, but with TCP/IP settings. Throw in a wireless client and it can be difficult to find a solution that fits. XML-RPC? SOAP? REST? Each way of communicating has benefits and drawbacks.

This is what we’re doing for client X, a niche healthcare business.

The requirements for the project are a web site with both static content and user-only pages with geolocation, pricing and communication features. These features are duplicated on iPhone/iPad and (in the future, Android) clients.

The obvious solution is an n-Tier architecture where we can centralize the business logic. The less obvious part is how to communicate with it. The iPhone app (Boomer) is using a wireless connection, so lightweight formats are obviously attractive. Also, iOS has a poor selection of XML-RPC and SOAP clients, so a JSON/REST solution makes sense.

On the other hand, the web client (Apollo) is running in the same location – initially on the same server – as the client, so it can use a fatter, more full-featured connection. Since we’re using Microsoft stack for this project, that means WCF. WCF also generates model code for the web client, so most of the work is just converting these models into HTML output. The server (Athena) consists of both conventional and restful WCF services each accessing the core logic of the server, which in turn consists largely of LINQ-based interaction with the database.

The neat thing about offering parallel services like this is that it makes adding additional transports much more straightforward. For example, if client X decides they want to use an RPC-based tool with the server, it just means adding another service; the business logic has already been prefactored out of the way.