在Windows 8 Metro应用应该如何连接到一个中央数据库？ [英] How should a Windows 8 Metro Application connect to a central database?

问题描述

在Windows 8 Metro应用应该如何连接到一个中央数据库？

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

• 我读过有关本地存储，但是我还没有有关连接到一个中央数据库读什么。


• 显然，这种建筑设计决定需要支持断开连接的情况。


• WCF Web服务似乎是有道理的。
  
  
  
  • 但是，即使他们这样做是有意义的，我们真的应该为所有读/写操作不同的方法？
  
  
  • 或者是OData的WCF服务的方式去？
  
  

  推荐答案

  看来，其他人都在问类似的问题<一href=\"http://social.msdn.microsoft.com/Search/en-US/windows/apps?query=database&rq=meta%3aSearch.MSForums.ForumID%2804848c5b-0a82-4be1-bab1-eab13c543e5a%29%20site%3amicrosoft.com&rn=Building%20Metro%20style%20apps%20with%20C#%20or%20VB%20%20Forum\">Microsoft开发者论坛。

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

  下面是我发现：

  <一个href=\"http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/e9cdd75d-03e4-4577-988e-4c02a52e3f50\">According蒂姆·豪雅：

  ...你不能直接嵌入在您的应用程序或使用SQL数据库
    像ADO.NET。这更多的是一个异步/服务
    基础设施。所以，如果你的数据是通过服务公开，那么，
    当然，你可以连接的方式。还有一些其他的轻量
    方法你可以使用本地存储以及使用的东西，如
    Windows.Storage命名空间（这类似于在独立存储
    .NET）。

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

  <一个href=\"http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/01896385-c75a-4c13-895b-ff4c653cd799\">Morten尼尔森同意：

  您可以使用的HttpClient来从网上下载pretty任何东西。
    你为什么不配置WCF服务的数据作为JSON返回，并
    使用DataContractJsonSerializer反序列化的结果？

  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?

  此外，<一个href=\"http://social.msdn.microsoft.com/Forums/en-BZ/winappswithcsharp/thread/1e03b3e7-7659-4407-ac07-a5a3db7a178c\">Tim豪雅警告：

  ...请注意，虽然真棒，在codePLEX的SQLWinRT项目是一个
    包装与经典的SQL​​ite的发动机...沟通，它使用
    API，这些API将无法通过验证店目前。

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

  通用对象存储帮手的WinRT 和的基于WinRTFil​​e数据库似乎还有些希望。

  ---

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

  但是，<一个href=\"http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/52c5459d-66b9-4706-b605-9a323abefd5b\">Daniel思多而特提出了一些很好的意见的：

  这真棒，有建设的OData客户良好的支持和
    其他REST客户 - 但这只是解决了网上的场景。该
    结构化Windows.Storage的一部分是非常有限的模式，
    基本上限于名称/值对，不足以但所有的
    最基本的场景。是的，有本地文件存储，这是伟大的
    当然。 但是每强迫应用程序开发人员在那里建立自己的
    对本地文件存储的顶级DBMS就干脆不会削减它，尤其是
    与所有的System.Data这已经从配置文件中删除。如果地方
    文件存储是足以满足大多数设备的应用程序，然后像的东西
    SQLCE今天就没有什么目的了。和SQLCE显然有
    宗旨，起到了非常重要的作用，为偶尔
    很长一段时间连接的设备的应用程序。也有一个巨大的
    需要同步与服务器端数据库如SQL
    天青，大多能够在设备之间漫游的数据。就在这里
    在WinRT中漫游存储模型，但它共享相同的局限性
    的上述本地存储，并在此之上是非常有限
    在容量（目前30KB如果没有记错）。这只不过是
    不足为所有，但最简单的漫游数据的需求。再次，
    迫使每一个应用程序开发者设计和实施自己的
    同步解决方案是非常糟糕的。你可以做的更好，使
    开发者。

  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.

  很多人感到失望的是System.Data命名空间不支持WinRT的

  ---

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

  <一个href=\"http://social.msdn.microsoft.com/Forums/en-AU/winappswithcsharp/thread/f3dcce6d-ce3d-4ffc-8f62-45c7c51be1c0\">Richard贝瑟尔说：

  我甚至不有这句话。这是惊人的。撇开对
    他们想要的那一刻强迫你抽象中间件
    数据库连接 - 我不同意，但我能理解准一
    理的。我甚至可以看到途径为这样的发展。

  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.

  但是，没有System.Data这....呢？你甚至不知道你做了什么
    我们呢？

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

  什么System.Data这可以做，对于SQL只是有供应商之外，
    OleDb的和其他定制供应商，如Oracle，是提供丰富
    XML数据集，使您可以非常快速地构建一个抽象
    面向数据的面向服务的架构。

  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.

  例如，我可以轻松地创建使用SOAP或WCF的Web服务
    返回数据集或数据表，然后轻松地使用这些对象
    和直接。如果能够做到这一点允许非常快速施工
    n层架构，即使没有直接的数据连接使用。

  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.

  如果没有System.Data和DataViews的电源，数据表等，这
    得到了很多困难。当然，你可以创建自定义结构，把数据
    在那里，和服务于结构，并使用LINQ做什么排序，
    过滤等你想做的事....但它最终被两次
    工作，使code重用了很多困难。这也意味着我们的使用
    现有的面向服务的架构是不可能的（没有大
    大修。）

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

  System.Data这的撤离是一样大的开发人员来处理事情
    与作为打印机对象在VB6流失到VB.NET 1.0了。什么
    是很难在这种情况下，要明白的是，为什么它是必要的 -
    重新启用它在新城轮廓不可能是一个技术
    该产品的难度，可以吗？

  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?

  有足够的有价值的我会认真考虑，包括Mono的
    System.Data这班我创建任何应用程序的一部分（这显然
    必须是开源的。）

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

  这篇关于在Windows 8 Metro应用应该如何连接到一个中央数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！