Targeting both cloud and self hosted application?

I'm planning to build an application that can be either hosted by the customer in a traditional manner or in the cloud (SaaS).

As there are many differences between the two targets, what are the guideli开发者_Go百科nes I have to follow to reduce future problems ?

I'm especially thinking about the persistence store... In one hand I have traditionnal RDBMS (SQL Server, Oracle, etc.) or maybe nosql systems like MongoDB, couchDb, etc. and in the other hand, I have to work with "proprietary" and specific storage (Azure Table, Sql Azure in the MS world).

I have the feeling it will be possible but with a lot of IOC, but as I'm new to the cloud, I'd appreciate any feedbacks.

Of course, I want (optimistic?) to be able to quite easily switch between approaches...

thx

You are thinking around the correct lines. When you designing your solution around a specific platform you should target the encapsulate the dependencies in a way that the consumer of the platform specific functionality is shielded from the implementation.This is where you do things like

• Create abtraction to the platform intefaces.
• Use IOC containers or any other approach to decouple components.
• Clearly seperating the plaform related code from other logic. For example if using Azure storage library keep the storage handling code in a seperate project altogether.

Easier said than done, but same holds good for Azure too. If the team is aware of these facts during design and development, you can have a solution which can be migrated to any virtualization platform.

SQL Azure is a large subset of SQL Server. From a programming perspectivem they are essentially equivalent (e.g. SP, tables, indexes, triggers, etc).

There are a few things which are ot enabled today or are different (e.g. no CLR, no Sql Broker, size limitations). You can write an app that minimizes or eliminates the dependency to those unsupported features and your app wil be more "portable".

Windows Azure Tables (and the other storage components) are Windows Azure specific. You will need to encapsulate components that use them and provide a compatible interface to other pieces of your app that depend on them. A classic example is the data access components. Or queue access for asynch communication.

IoC/DI can help but they are not mandatory.