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

Question

我有一个Silverlight Windows Phone 7应用程序,它从公共API中提取数据.我发现自己一遍又一遍地做同样的事情:

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

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

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

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

我的问题是:

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

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

这是我想到的设计:

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

View给出了FrameworkElement加载,失败和成功的信息.它还给出了相应模型的参考.视图UserControl位于UI中的某个位置.

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

听上去怎么样？

Answer 1

Mic*_*k N 4

我花了一些时间仔细阅读了您的要求，并提出了一些想法，可以作为参考。

首先，对于具有共同行为的重复性任务，这绝对是解决问题的方法。您并不是唯一一个思考这个问题的人。

做大量此类事情的人可能已经创建了类似的抽象，但据我所知，没有一个被公开发布。

您能走多远可能取决于您是否打算将其仅供您自己使用以及具有非常相似需求的人使用，或者您是否想要处理更一般的情况并制作可供广泛受众使用的产品。

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

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

我认为总的来说你的想法是正确的。在阅读您的一些高层次想法时，我认为有些事情可以简化（这是一件好事），同时提供令人信服的用户界面。

关于你最初的观点。

您可以假设正在传入性能不确定的进度条。
如果这对您很重要，请执行此操作，但您可能会在处理不同的缓存要求时陷入一些复杂性 - 持续时间的差异或脏处理。也许足以依靠平台内置的 url 缓存（有些人发现这妨碍了他们）。
处理网络连接，是的，这是重复的并且有些复杂。通用解决方案的完美候选者。
更新 UI...可以说，最好只返回数据并推迟有关数据呈现和格式的决策给您的个人客户。
主内存中的内容 - 请参阅上面有关缓存的内容。

关于您的潜在投入。

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

关于实施。

您可以使用 UserControl，如果它适合您受该假设的约束。不过，将数据显示和状态消息的呈现推回客户端并控制传入的进度条的隐藏/显示会更灵活，并且可以说同样简单/优雅。
也许您甚至会假设状态消息始终显示在文本块中（如果通过），并将每个客户端的内务处理转移到您的通用类中。
我怀疑您仍然会受益于不耦合数据格式和表示形式。
墓碑处理.. 我建议在此处的内置 URL 缓存中的平台上进行一些测试，看看您是否可以确定其持续时间/脏条件是否适用于您的一般情况。

希望这能让您思考一些事情，并保证您正在走上正确的道路。有很多方法可以解决这个问题。哪条最好的道路最终将由您的目标驱动。