Silverlight 和应用程序状态

发布于 2024-10-02 01:16:49 字数 273 浏览 1 评论 0原文

我有一个 Silverlight 应用程序,它始终需要知道当前加载的客户(域对象)。一次只能加载一个。如果Customer为null,则当前没有加载任何Customer。或者您退出了客户。我将拥有另外 3 个状态类型属性,例如 Customer。那么...

在 Silverlight 应用程序中存储应用程序状态的最佳方法是什么?

1)向App类(App.xaml.cs)添加公共属性
2) 有一个状态对象,您可以通过 IoC 容器将其新建为单例。向该对象添加公共属性 3)还有其他想法吗?

I have a Silverlight app that always needs to know what Customer (domain object) is currently loaded. There can only be one loaded at a time. If the Customer is null, no Customer is loaded currently. Or you exited a Customer. I'm going to have 3 more state-type properties like Customer. So...

What is the best way to store application state in a Silverlight application?

1) add public properties to the App class (App.xaml.cs)
2) have a state object that you can new up as a singleton via your IoC container. add public properties to this object
3) any other ideas?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

时常饿 2024-10-09 01:16:49

我的投票支持你的第二个选择,即拥有一个状态对象单例。如果您使用 MVVM 和 Silverlight 工具包,那么您将在 MainViewModel 中内置一个工具包,它是静态的并在 ViewModelLocator 中静态初始化。那将是实现您想要的结果的完美场所。

My vote would be for your second option, to have a state object singleton. If you are using MVVM and the Silverlight Toolkit, then you would have one built right into your MainViewModel which is static and statically initialized in the ViewModelLocator. That would be a perfect place to accomplish your desired result.

喵星人汪星人 2024-10-09 01:16:49

我会选择第二种选择。

目前正在开发一个存储域对象状态数据的 Silverlight 应用程序。

我们有一个所谓的 ApplicationManager,它通过 IoC 解析来存储参考数据和域数据。可能有比 ApplicationManager 更好的术语,但迄今为止尚未找到标准的命名约定。

这个概念运作良好,我们所有的视图模型都可以访问 ApplicationManager,因此当应用程序的另一部分需要采取操作时,我们传递的只是实体 ID。

如果您有更新数据的异步操作,则需要注意保持 UI 和数据存储的一致性

I would go for the second option.

Currently working on a Silverlight application that stores state data of domain objects.

We have what has been termed an ApplicationManager that is resolved via IoC to store reference data and domain data. There might be a better term than ApplicationManager, but to date have not found a standard naming convention.

The concept works well, all of our View Models have access to the ApplicationManager, so all we pass around is entity id's when another part of the application needs to take action.

If you have asynch operations updating the data you need to be mindful of keeping the UI and data store consistent

被翻牌 2024-10-09 01:16:49

我有类似的问题。当我使用 MEF 时,我创建了一个保存数据的服务。您可以在需要的地方导入服务并有权访问引用的对象。 (所以和2类似)

I had a similar problem. As I am using MEF, I created a service which holds the data. The you can import the service where you need it and have access to the referenced objects. (So it is similar to 2)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文