Question

How should a Windows 8 Metro application connect to a central database?

• I’ve read about local storage, but I haven’t read anything about connecting to a central database.
• Obviously, this architectural design decision needs to support the disconnected scenario.
• WCF web services seem to make sense.
  • But even if they do make sense, should we really create separate methods for all read/write operations?
  • Or are OData WCF services the way to go?
• It seems like tablet software architecture should be able to borrow a lot from smartphone software architecture (but I am new to both).
• Has Microsoft made any recommendations in its app samples?

Answer 1

It appears that others are asking similar questions on the Microsoft Developer Forums.

Here is what I’ve found:

According to Tim Heuer:

…You cannot directly have a SQL db embedded in your app or use
something like ADO.NET. This is more of an async/services
infrastructure. So if your data was exposed via services, then of
course you could connect that way. There are some other light-weight
methods you could use for local storage as well using things like the
Windows.Storage namespace (which is similar to Isolated Storage in
.NET).

Morten Nielsen agrees:

You can use HttpClient to download pretty much anything from the web.
Why don’t you configure your WCF service to return data as JSON, and
use the DataContractJsonSerializer to deserialize the results?

Also, Tim Heuer cautions:

…Please note that while awesome, the SQLWinRT project on codeplex is a
wrapper to communicate with the classic SQLite engine…which uses
APIs that would not pass store validation currently.

---

Generic Object Storage Helper for WinRT and WinRTFile Based Database seem to have some promise.

But Daniel Stolt raises some good points:

It’s awesome that there is good support for building OData clients and
other REST clients – but this only addresses the online scenario. The
“structured” part of Windows.Storage is a very limited model,
essentially limited to name/value pairs, insufficient for all but the
most basic scenarios. Yes there is local file storage, which is great
of course. But forcing every app developer out there to build her own
DBMS on top of local file storage will simply not cut it, especially
with all of System.Data having been removed from the profile. If local
file storage was sufficient for most device apps, then things like
SQLCE would have no purpose today already. And SQLCE clearly has a
purpose, and has played a very important role for occasionally
connected device apps for a very long time. There is also a tremendous
need for synchronization with a server-side database such as SQL
Azure, mostly to be able to roam data between devices. Yes there is
the roaming storage model in WinRT, but it shares the same limitations
of local storage mentioned above, and on top of this is very limited
in capacity (currently 30KB if memory serves). It is simply
insufficient for all but the simplest roaming data needs. Again,
forcing every app developer to design and implement her own
synchronization solution is very bad. You can do much better to enable
developers.

---

Many people are disappointed that the System.Data namespace is not supported in WinRT.

Richard Bethell said:

I don’t even have words for this. This is astonishing. Leave aside for
the moment they want to force you to abstract to middleware for
database connectivity – I don’t agree, but I can quasi understand a
rationale for that. I can even see pathways for developing like that.

But no System.Data…. at all? Do you even understand what you’ve done
to us?

What System.Data can do, outside of just having providers for Sql,
OleDb and other custom providers like Oracle, is provide a rich
abstraction of XML datasets that allow you to very quickly build a
data oriented Service Oriented Architecture.

For instance, I can easily create a web service using SOAP or WCF that
returns DataSets or DataTables, and then consume those objects easily
and directly. Being able to do this allows very rapid construction of
n-tier architectures, even without direct data connections available.

Without System.Data, and the power of DataViews, DataTables, etc. this
gets a lot harder. Sure you can custom create structs, put data in
there, and serve up structs, and use Linq to do whatever sorting,
filtering, etc. you want to do…. but it ends up being twice the
work, and makes code reuse a lot harder. And it means using our
existing service oriented architecture is impossible (without a big
overhaul.)

The withdrawal of System.Data is as big a thing for developers to deal
with as the loss of the Printer object in VB6 to vb.net 1.0 was. What
is harder to understand in this case is why it is necessary –
re-enabling it in the Metro profile can’t possibly be a technical
difficulty of the product, can it?

It is valuable enough that I would seriously consider including Mono’s
System.Data classes as part of any app I create (which would obviously
have to be open source.)