最佳仪表板架构

ABJ*_*ABJ 13 javascript java architecture user-interface

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

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

什么样的应用程序可以成为一个好的架构?

我目前的想法是:

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

Eva*_*van 9

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

一些谷歌搜索可以提供每个的利弊,我会相应地权衡你的选择.

总而言之,你提出的基本问题实际上与我们的相似.最后,我们在内部建造了一些不同的东西.许多框架都经过优化,可以根据DB和Controller反映的模型显示单一的规范"视图",以管理小的变化.事实上,仪表板上有各种不同的模块,必须按照你在问题中提到的那样独立完成.由于大量的独立模块,我觉得你可能会对上面列出的一些框架感到痛苦.

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

模块设计:

  • 模块为主.(登录模块,地图模块,每个Dashlet可能是一个模块等)
  • 模块必须有一个Model,可能只有一个Collection(也就是一个Model),并且可能有一个或多个Views.
  • 模块可以在多个地方和页面中使用.单数模型应保持不变,但视图可能不同.

渲染:

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

正交:

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

连接到后端:

  • 所有模块都使用相同的全局后端适配器.模块永远不会自己与后端通信.这使您的前端后端不可知.

递归:

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

可测试的:

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

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


Mic*_*Mic 1

我们的网络应用程序正是基于此架构,并自去年年底开始投入生产。您可以在http://beebole.com上看到它

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

然后,如果小部件需要附加数据,它会自行调用我们的服务器。外部小部件也调用自己的数据,但调用的是另一台服务器。