Visual Studio vNext (aka Orcas) has a number of features that is set to make building occasionally connected applications really really easy. Since downloading the Beta 1 bits I have been trying to get my head around all the improvements and changes that Microsoft have added. I must admit the overall stability of Visual Studio is quite good – I’ve only had it crash once or twice and that was actually the compiler that seemed to die rather than the IDE itself.
The first thing about building an Occasionally Connected application (OC App) is that you need to think about how you are going to work with the data. Unlike traditional applications which typically connect directly to a central database (whether they be a winforms or web app) OC Apps need to have data available when they are offline. This means having a local datastore – with the release of SQL Server Compact Edition (v3.1) earlier this year this decision is now quite easy. Orcas will ship with v3.5 of SQL Server CE which has some minor improvements around synchronisation.
This leads me to the next problem – how do I synchronise data from the central database to the local datastore (ie my Sql Server CE database)? In the past we had to choose between building this ourselves (eg using webservice with some data structure, perhaps datasets), using RDA or Merge Replication. Last year Steve Lasker started talking about OCS or, as it is now called, the Microsoft Synchronisation Services. This is a framework for building logic that will synchronise data between a “client” and a “server” – although the first release will focus on supporting the SQL Server CE (client) to SQL Server (server) scenario, there is no reason why you can’t do SQL Server Express to SQL Server, or even SQL CE or SQL CE.
MS Sync Services, as I mentioned in a previous post, also has designer support within Orcas. Although the designer in Beta 1 has changes somewhat (the “Synchronisation” group box is no longer there – you have to build your own logic around when synchronisation is triggered) it still builds the majority of the functionality you need to be able to get syncing (more on what works/doesn’t work in a later post). This designer can output both the client and server code. Of course building an occasionally connected application we want to put the client code in our application and the server code in a webservice or WCF project (more on configuring this in a further post).
Now that we have a local datastore (SQL Server CE) that is setup to synchronise with the central database (using MS Sync Services) we now need to be able to read and write to the database, and to bind data to UI controls. This can all be done using Linq to Entities. As a few people have noted in Beta 1 there are a few issues with the Entities designer but if you are happy to work with the command line tool this can save you a lot of work accessing your data. Once you have setup the Entity models you can then use Linq to pull back a set of objects (strongly typed of course) from the database. These can then be bound to your UI using a binding source (the same as you would have done in VS2005). You can even add/remove items using the Navigation control. When you are done making changes all you need to do is call SaveChanges on the data context and you are done – this commits changes to the local database, you need to synchronise for these changes to be persisted to the server!
This gives you an overview of how Orcas can facilitate building occasionally connected applications. I will follow this up with posts that go into more detail about some of these features – in particular the areas that are currently broken and some gotchas!