如何:Windows Phone 中的数据持久性
我正在编写一个 Windows Phone 应用程序。我想要做的是,当应用程序启动时,它会获取一些数据(设置或其他内容),并且我希望这些数据在应用程序的整个生命周期中持续存在;即我不想在需要该数据时继续读取IsolatedStorage或调用服务器。
执行此操作(加载和共享)的最佳方法是什么?请记住以下几点:
- 我希望它符合 MVVM 标准
- 我正在使用 Caliburn.Micro
- 数据不是只读。
- 该应用程序具有多个共享数据的页面/视图和视图模型
提前致谢。
I'm writing a Windows Phone application. What I want to do is, when the application starts it gets some data (settings or whatever), and I want this data to persist throughout the life of the application; i.e. I don't want to keep reading the IsolatedStorage or calling the server whenever I need that piece of data.
What is the best way to do this (load and share)? Having in mind the following:
- I want it to be MVVM compliant
- I'm using Caliburn.Micro
- The data is not read-only.
- The application has more than one page/View and ViewModels that share the data
Thanks in advance.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
Phil 提到的静态类是一个好主意,但我建议考虑使用依赖注入。您可能不需要完整的 IoC 容器,但这可能会对您的场景有所帮助。 Caliburn.Micro 使得集成这样的容器变得非常容易。
创建一个
Settings
类。 (我还会创建一个ISettings
接口,以便您可以将存根设置传递到视图模型中进行测试,但这是一个额外的好处。)然后使所有 ViewModel 都需要一个ISettings 实例
在他们的构造函数中。当您的应用启动时,您将创建一个
Settings
实例,该实例从isolatedStorage 或您拥有设置的其他位置读取数据,然后将该实例传递到创建的任何 ViewModel 中。该
Settings
类可以负责在需要时将设置保存回isolatedStorage。此场景的一个示例:
在
AppBootstrapper
类中:在您的 ViewModel 类中:
此时,您将拥有可用于 ViewModel 的所有设置。
A static class as Phil mentions is a fine idea, but I would suggest looking into using dependency injection. You may not need a full IoC container, but that would probably help for your scenario. Caliburn.Micro makes it very easy to integrate such a container.
Create a
Settings
class. (I would also create anISettings
interface so that you could pass stub settings into your view models for testing, but that's an extra bonus.) Then make all of your ViewModels require an instance ofISettings
in their constructors.When your app starts, you create one instance of
Settings
that reads from IsolatedStorage or wherever else you have settings, then pass that instance into any ViewModel that gets created.That
Settings
class can be responsible for saving settings back to IsolatedStorage whenever it needs to.An example of this scenario:
In
AppBootstrapper
class:In your ViewModel class:
At this point you will have all your settings available for your ViewModel.
如果我正确理解您的问题,您可以使用其中包含静态成员的静态类。只要您在想要使用成员的地方引用此类,只要应用程序正在运行,它们就会存在。
如果我误解了“应用程序寿命”,我会用另一个解决方案更新答案
If I've understood your question correctly you could use a static class with static members in it. As long as you reference this class where you want to use the members, they'll exist as long as the app is running.
I'll update the answer with another solution if I've misunderstood "application life"
使用 Caliburn micro,我喜欢创建一个 SharedData 类并将其作为单例在容器上注册。然后将其注入到任何需要使用它的 ViewModel 中。 CM 中的导航服务还可以使用 .WithParam 在页面之间轻松传递 dta。
编辑:我刚刚意识到这基本上就是丹尼斯所说的。我还提到,我还使用 SterlingDB 在 ViewModel 之间保存一些内容。
With Caliburn micro I like to create a SharedData class and register it on the container as a singleton. Then inject it into any ViewModels that need to use it. The Navigation service in CM also makes passing dta between pages simple using .WithParam.
Edit: I just realized this is basically what Dennis said. I also mention that I also use SterlingDB for persisting some things between ViewModels.
我误解了 Caliburn 是什么 - 我以为,出于某种原因,它是一个 DI 容器。既然不是,那么我建议使用一个。就我个人而言,我会使用 OpenNETCF IoC 因为我熟悉它,但任何支持的容器都可以工作。在应用程序初始化时,加载您的设置和应用程序生命周期所需的任何其他服务,并将它们放入 DI 容器中(或让容器为您创建它们)。
对于 IoC,它在应用程序初始化中看起来像这样:
或者
然后在应用程序中您想要它们的任何位置,您可以通过接口类型拉取(解析):
并使用返回的实例。在所有情况下,您都可以使用具体类型而不是接口,但我更喜欢使用接口来更轻松地进行测试和模拟。
I misunderstood what Caliburn is - I was thinking, for some reason, it was a DI container. Since it's not, then I'd recommend using one. Personally I'd use the OpenNETCF IoC because I'm familiar with it, but any supported container would work. On app initialization, load your settings and any other services you want for the life of the app and put them into the DI container (or have the container create them for you).
For IoC that would look like this in the app initialization:
or
Then anywhere in the app at all that you want them, you pull (resolve) by interface type:
And use the returned instance. You can use the concrete type instead of an interface in all cases as well, but my preference is to use interfaces to allow easier testing and mocking.