web-services - Windows 8 Metro应用程序应如何连接到中央数据库？

Question

Windows 8 Metro应用程序应如何连接到中央数据库？

我已经阅读了有关本地存储的信息，但是我还没有阅读有关连接到中央数据库的任何信息。

显然，此体系结构设计决策需要支持断开连接的场景。

WCF Web服务似乎很有意义。

但是，即使它们确实有意义，我们是否真的应该为所有读/写操作创建单独的方法？

还是OData WCF服务走的路？

看来平板电脑软件体系结构应该能够从智能手机软件体系结构中借鉴很多(但是我对这两者都是陌生的)。

Microsoft是否在其app samples中提出了任何建议？

Answer 1

似乎其他人也在Microsoft Developer Forums上问了类似的问题。

这是我发现的:

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?

另外，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和WinRTFile Based Database似乎有希望。

但是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.

许多人对WinRT不支持System.Data命名空间感到失望。

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