How should a Windows 8 Metro Application connect t

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?

回答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.)

回答2:

I think that this is another of those "it depends" questions...

The first and most obvious issue is that it very much depends on the context in which the application is running as to whether, to take the first case "Obviously...support...disconnected" is actually true - if the app is an internal corporate app then quite possibly not in that case no db == not work.

Secondly you could look (hmm, rash... one assumes you could look, this could be a bad assumption) at database synchronisation between a local SQL database and the remote db and so on and so forth.

Taking a step back... yes - you're absolutely right, look at it as being the same as phone or silverlight (although I don't know if there is yet RIA support) - but the thing is at this point its very hard to be prescriptive because given a general purpose platform one can therefore write applications to suit all sorts of purposes.

Not a hugely helpful answer really - but a start.

Having read @Jim G's answer it seems that I should probably withdrawn mine?