【问题标题】:Best Dashboard Architecture最佳仪表板架构
【发布时间】:2011-10-09 03:12:33
【问题描述】:

我需要为应用程序构建仪表板,仪表板将具有不同的 dashlet,每个 dashlet 可以包含以下任何一项:

  1. 图表(JFreeCharts 和一些 Javascript 图表)
  2. 表格中的表格数据
  3. 来自外部的数据
  4. 地图

对于这类应用程序来说,什么是好的架构?

我目前的想法是:

  1. 每个 dashlet 都应该有自己的生命周期,当仪表板加载时,它最初应该只显示 dashlet 的 UI。
  2. 页面加载后,每个 dashlet 都会发送一个服务器调用(基于其类型)以获取其数据
  3. 获取数据后,每个 dashlet(基于其类型)呈现数据。

【问题讨论】:

    标签: java javascript architecture user-interface


    【解决方案1】:

    我们的网络应用完全基于这种架构,并于去年年底投入生产。你可以在http://beebole.com看到它

    我们刚刚优化了对我们自己的服务器的调用。 每次加载屏幕时,只需一次调用即可获取大多数小部件所需的通用数据。

    如果一个小部件需要额外的数据,它会自己调用我们的服务器。 外部小部件也调用它们自己的数据,但调用另一个服务器。

    【讨论】:

    • 感谢您的回复,因为您的正在生产中,所以非常放心。
    • 一个问题,如果我理解正确的话,当页面加载时它会加载所有引用您自己服务器的小部件及其数据?对吗?
    • 每个小部件都是一个网页,包含其 HTML、JS 和 CSS。一旦它们被加载,如果它们没有足够的数据(已经从第一次调用或其他小部件中获得),它们就会调用我们的服务器。
    • 如果您能写一篇关于如何为 bee-bole 应用程序创建仪表板的教程,那就太好了!它非常令人印象深刻!
    • @xerxes,主要是CSS/DIV的组合。例如,在 Dev Tools 或 Firefox 中检查其中一个滑块,您将看到周围的 DIV 是如何制作的。做到这一点并不容易,但结果我认为很容易理解。
    【解决方案2】:

    首先,有很多前端框架可以帮助您入门。一些比较流行的包括:

    一点谷歌搜索可以得出每个的优缺点,我会相应地权衡你的选择。

    话虽如此,您提出的基本问题实际上似乎与我们的相似。最后,我们在内部建造了一些不同的东西。那里的许多框架都经过优化,可以显示基于数据库反映的模型和控制器的单一规范“视图”,以管理小的变化。正如您在问题中提到的那样,仪表板本质上具有各种不同的模块,它们必须做自己独立的事情。由于大量的独立模块,我觉得您可能会对上面列出的一些框架感到痛苦。

    我不能确切地告诉你如何实现这样的模块架构,但这里有一些我们在设计时使用的经验法则:

    模块设计:

    • 基于模块。 (登录模块、地图模块、每个Dashlet可能是一个模块等)
    • 模块必须有一个模型,不能超过一个集合(即模型),并且可以有一个或多个视图。
    • 一个模块可以在多个地方和页面中使用。单一模型应该保持不变,但视图可能不同。

    渲染:

    • 页面上几乎所有的 HTML 都是由 javascript 模块编写和更新的。除了标题和基本脚手架之外,模板文件几乎是空的。
    • 所有模块都呈现其完整的 HTML 自身并将自身替换到 DOM 中。在插入 DOM 之前,该模块应该具有完整的静态 HTML 表示。这意味着渲染函数使用“.replaceWith()”而不是“.append()”。
    • 如果不能选择简单的 HTML 替换(即需要动画),则应定义转换函数,详细说明如何从一种渲染状态转到另一种渲染状态。
    • 因为渲染开销很大,默认情况下视图不会在所有模型更改时自动刷新。重新渲染仅通过事件发生。 _render() 实际上是一个内部方法。

    正交性:

    • 页面控制器上的单个模块间事件调度程序处理模块之间的所有交叉影响。
    • 模块不应该“到达”它们自己的 DOM 上下文之外。如果一个模块中的事件影响另一个模块,它应该通过页面控制器调度程序。
    • 每个模块尽可能正交。他们尽可能少地相互依赖。
    • 每个模块都在自己的文件中。

    连接到后端:

    • 所有模块都使用相同的全局后端适配器。模块从不自己与后端对话。这使您的前端后端不可知。

    递归

    • 模块通常包含在其他模块中。
    • 模块以递归方式重新渲染。

    可测试

    • 由于模块呈现静态 HTML,因此可以对它们进行可预测的测试。
    • 模块必须是可测试的。
      • 标准输入 -> 模块 -> 可预测的静态 HTML 输出。
      • 标准事件 -> 模块 -> 可预测的静态 HTML 输出。

    如果有人知道这些方面的其他框架,请分享!

    【讨论】:

      【解决方案3】:

      当有这么多可用的免费框架时,我建议不要使用自定义 Web 框架。

      正如另一个答案中提到的,传统的 MVC 样式框架并不适合您的“仪表板”所需的 UI 样式。它们最适合用于根据在别处检索到的数据创建静态网站。它们不能很好地处理用户交互,您通常必须手动滚动自己的 AJAX 才能在没有页面请求的情况下执行任何有用的操作。

      Web 2.0 框架,也称为帮助您构建 Web 应用程序的框架,是一种更好的 Web 框架类型。了解网站和 Web 应用程序之间的区别很重要。它们的区别通常在于后者是交互式的,而前者主要是静态的。也有一些交互组件的网站仍然是网站。思考它的一个好方法是问自己“这感觉像桌面应用吗?”。

      对于 Java (JVM) 领域的 Web 应用程序开发,我会使用 Vaadin。它允许您使用基于事件的方法编写类似于 Swing 编程的 Java 代码。如果您愿意,您甚至可以通过以编程方式定义视图来完全避免编写 HTML。这使您可以对基于常规 HTML 模板的框架无法实现的视图逻辑进行单元测试(在 Web 应用程序中,比平常更多)。另一个主要优点是它内置了允许您编写 Java 代码来处理动态、异步功能的方法,并且所有这些都可以自动转换为 JavaScript。编写 Web 应用程序时无需编写 4 种不同的语言,只需为所有内容编写 Java!试试看,工作很有趣!

      另一个受到广泛关注的 Web 应用程序框架是 Lift。我没有这方面的经验,但与我交谈过的许多开发人员都向我推广了它。我相信它使用带有 Java 代码的 HTML 模板作为后端。它显然也很容易上手,并且您的网络应用程序启动了。它还内置了对执行类似 AJAX 的功能的支持。至少值得研究一下。

      可能还有更多的 Web 应用程序框架可以满足您的需求。这些都具有经过测试、独立维护、更新和安全的优势*。如果你为这个项目推出自己的框架,你需要自己担心一切。编写一个不提供任何新东西的 Web 框架就像编写另一种没有创新性的编程语言一样;这只是浪费时间。

      【讨论】:

        【解决方案4】:

        我认为您正在寻找的更多是管理或控制仪表板。我正在设计类似的东西。我建议你看看谷歌应用引擎它可以用来自动化和控制这个:https://developers.google.com/appengine/docs/whatisgoogleappengine

        还可以查看这些开源仪表板:https://github.com/twilio/stashboard

        【讨论】:

          猜你喜欢
          • 2019-05-14
          • 1970-01-01
          • 2015-09-11
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2014-03-30
          • 1970-01-01
          • 2015-01-18
          相关资源
          最近更新 更多