数据驱动的Silverlight WP7应用程序的架构设计

概述我有一个Silverlight Windows Phone 7应用程序,可以从公共API中提取数据.我发现自己一遍又一遍地做同样的事情： >在UI中,设置加载消息或加载进度条以代替内容的位置 >获取可能已在内存中的内容,缓存在隔离的文件存储中,或者需要HTTP请求 >如果无法获取内容(无网络连接等),则显示错误消息 >如果获取了内容,请在UI中显示 >将内容保留在主内存中以供后续查询使用 显示给用 我有一个Silverlight Windows Phone 7应用程序,可以从公共API中提取数据.我发现自己一遍又一遍地做同样的事情：

>在UI中,设置加载消息或加载进度条以代替内容的位置
>获取可能已在内存中的内容,缓存在隔离的文件存储中,或者需要http请求
>如果无法获取内容(无网络连接等),则显示错误消息
>如果获取了内容,请在UI中显示
>将内容保留在主内存中以供后续查询使用

显示给用户的内容可以直接从数据源(如ObservableCollection)获取,也可以是对数据源的查询.

我想将这个重复的过程分解成一个框架,理想情况下只需要指定以下内容：

>在UI中显示内容的位置
>在加载,失败和成功时显示的UI元素
> http请求的URI
>如何将http响应解析为将保留在内存中的数据结构
>文件在隔离存储中的位置(如果存在)
>如何将文件内容解析为将保留在内存中的数据结构

听起来可能很多,但是两个字符串,三个FrameworkElements和两个方法比我目前的开销要少.

此外,这需要工作,但数据在内存中维护,并且需要在这些集合上进行直接收集和查询.

我的问题是：

这样的事情已经实施了吗？

我对上述主题的看法在某种程度上是根本错误的吗？

这是我正在考虑的设计：

有两个组件,一个视图和一个模型.

VIEw给出了FrameworkElements的加载,失败和成功.它还提供了相应模型的参考. VIEw是一个位于UI中某处的UserControl.

Model是一个给出数据URI的类,一个如何解析数据的方法,以及一个文件名和如何解析文件的方法.它负责检索数据并在当前状态(加载/失败/成功)发生变化时通知VIEw.如果从网络下载的数据与缓存不同,则网络数据优先.当应用关闭或被逻辑删除时,模型会将数据写入缓存.

听上去怎么样？

解决方法 我花了一些时间来仔细阅读你的要求,并注意到一些想法作为一个发声板.

首先,对于具有共同行为的重复性任务,这绝对是接近它的方法.你并不是唯一一个想到这个问题的人.

做一堆这类事情的人可能已经创建了类似的抽象,但据我所知,没有人公开发布.

如果你想要它只是为了你自己的使用和那些有非常相似要求的人,或者你是否想要处理更多的一般情况并制作一个可供广大观众使用的产品,你可以在多大程度上依赖它.

我将假设前者,但这并不排除将其作为可以进一步开发和/或分叉的开源项目发布的可能性.

通过不尝试满足所有可能性,您可以对使用实现的性质以及特别是UI设计选择做出某些假设.

我认为你的思维方向正确.在阅读您的一些高级想法时,我认为有些事情可以简化(一件好事),同时提供一个强大的用户界面.

在你的初始点.

>您可以假设正在传递的性能是确定进度条.
>这样做对你来说很重要,但是你可能会在这里处理一些复杂的处理不同的缓存要求 – 持续时间的变化或处理不当.也许足以依靠平台内置的网址缓存(有些人发现它们会阻挡它们).
>处理网络连接,是的,这是重复的,有点错综复杂.一般解决方案的完美候选者.
>更新UI …可以说更好地返回数据并将有关数据的表示和格式的决定推迟到您的个人客户.
>主内存中的内容 – 参见上面的缓存.

关于你的潜在投入.

>在何处显示内容 – 请参阅上述重新数据并将演示文稿选择推迟到客户端.
>我会使用UI元素作为进度指示器,同样是一个高性能的进度条.关于失败的沟通,我会考虑在您发布的已完成事件中实现此功能.然后通过参数,您可以传达结果并将处理推迟到客户端,以将结果放在一些表示控件/日志/任何内容中.这与.Net Framework使用的模式一致.
> URI – 是的,这会被传入.
>如何解析 – 传递委托以将流或字符串转换为可由客户端决定其类型的对象是有意义的.
>缓存的位置 – 你可以传递这个,如果这很重要,或硬编码它的路径.如果传入,对其他人来说会更有用(考虑一下你是否处理文件夹/创建).

关于实施.

>你可以使用UserControl,如果它适合你受这个假设的约束.它会更加灵活,并且可以说同样简单/优雅,可以将演示文稿推回到客户端上,用于数据显示和状态消息,并控制传入的进度条的隐藏/显示.
>也许你会假设状态消息总是显示在一个文本块中(如果通过),并将每个客户端的内务处理转移到你的泛型类中.
>我怀疑你还会因为没有耦合数据格式和演示文稿而受益.
>墓碑处理..我建议在这里建立缓存URL的平台上进行一些测试,看看你是否可以确定它的持续时间/脏条件是否适用于你的一般情况.

希望这能给你一些思考的东西,并保证你会走上正确的道路.有很多方法可以解决这个问题.哪条路最终将由您的目标驱动.

总结

以上是内存溢出为你收集整理的数据驱动的Silverlight WP7应用程序的架构设计全部内容，希望文章能够帮你解决数据驱动的Silverlight WP7应用程序的架构设计所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。