数据驱动Silverlight WP7应用程序的体系结构设计

我有一个Silverlight Windows Phone 7应用程序，可以从公共API提取数据。我发现自己一次又一次地做着同样的事情：

• 在UI中，将加载消息或加载进度条设置为内容所在位置
• 获取内容，这些内容可能已经在内存中，缓存在独立的文件存储中，或者需要HTTP请求
• 如果无法获取内容（无网络连接等），则显示错误消息
• 如果获取了内容，则在UI中显示该内容
• 将内容保留在主存中，以便后续查询

显示给用户的内容可以直接从数据源获取，例如

可观察收集

，也可以是对数据源的查询

我想将这个重复的过程考虑到一个框架中，在这个框架中，理想情况下只需要指定以下内容：

• 在UI中显示内容的位置
• 加载、失败和成功时要显示的UI元素
• HTTP请求的URI
• 如何将HTTP响应解析为将保存在内存中的数据结构
• 文件在独立存储中的位置（如果存在）
• 如何将文件内容解析为将保存在内存中的数据结构

听起来可能很多，但是两个字符串、三个

FrameworkElement

s和两个方法比我目前的开销要小

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

我的问题是：

已经实施了类似的措施吗？

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

这是我想到的一个设计：

有两个组件，一个视图和一个模型

视图中给出了加载、失败和成功的

框架元素。同时也为相应的模型提供了参考。该视图是一个
UserControl
，位于UI中的某个位置

该模型是一个为数据提供URI的类，一个解析数据的方法，以及可选的文件名和解析文件的方法。它负责检索数据并在当前状态（加载/失败/成功）更改时通知视图。如果从网络下载的数据与缓存不同，则网络数据优先。当应用程序关闭或被删除时，模型会将数据写入缓存

听起来怎么样？
我花了一些时间仔细阅读了您的要求，并记下了一些想法，以供参考

首先，对于具有常见行为的重复性任务，这绝对是解决方法。思考这个问题的不止你一个人

做这类事情的人可能已经创建了类似的抽象概念，但据我所知，还没有公开发布过

您使用它的程度可能取决于您是否打算将其仅用于您自己的用途以及那些具有非常相似要求的用途，或者您是否希望处理更一般的情况，并使产品能够被非常广泛的受众使用

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

通过不尝试迎合所有可能性，您可以对使用实现的性质做出某些假设，尤其是UI设计选择

我认为你的总体思路是正确的。在阅读您的一些高级想法时，我认为有些事情可以简化（一件好事），同时提供一个有竞争力的UI

关于你最初的观点


您可以假设正在传入一个性能IsIndeeterminate progressbar
如果这对您很重要，请这样做，但您可能会在处理不同的缓存需求时陷入某种复杂性—持续时间的差异或脏处理。也许足以依靠平台内置的URL缓存（有些人发现这会妨碍他们）
处理网络连接，是的，这是重复的，有点复杂。一般解决方案的完美候选者
更新用户界面。。。可以说，最好只是返回数据，并将有关数据表示和格式的决定推迟到您的个人客户
主内存中的内容-请参阅上面关于缓存的内容

你的潜在投入


在何处显示内容-请参阅上面的“重新数据”，并将演示选择推迟到客户端
我会使用一个UI元素作为进度指示器，同样是一个性能进度条。关于失败的沟通，我会考虑在完成的事件中实现这一点。然后，通过参数，您可以将结果与客户机进行通信，并将处理延迟到客户机，以便将该结果放入一些表示控件/日志/任何内容中。这与.Net Framework使用的模式一致
URI-是的，这会被传入
如何解析-传入委托以将流或字符串转换为可由客户端决定其类型的对象是有意义的
缓存的Loc-如果泛化这个问题，您可以传递它，或者硬编码它的路径。如果传入，它将对其他人更有用（请考虑是否处理文件夹/创建）

关于执行问题


您可以使用UserControl，如果它能让您受到该假设的约束。不过，将数据显示和状态消息的演示文稿推回到客户端，并控制传入的进度条的隐藏/显示，这将更加灵活，可以说同样简单/优雅
也许你会走到