最佳仪表板体系结构

首先，有很多前端框架可以帮助您入门。一些比较受欢迎的包括：

• 骨干
• Javscript MVC
• 萌芽核心

一些谷歌搜索可以使每个的利弊，我会相应地权衡你的选择。

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

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

模块设计：

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

渲染：

• 页面上几乎所有的HTML都是由javascript模块编写和更新的。除了标头和基本基架之外，模板文件几乎为空。
• 所有模块都呈现其完整的HTML自我，并将自己替换到DOM中。在插入 DOM 之前，模块应准备好完整的静态 HTML 表示形式。这意味着渲染函数使用“.replaceWith（）”而不是“.append（）”。
• 如果简单的HTML替换不是一个选项（即需要动画化），则应定义一个转换函数，详细说明如何从一个呈现状态转到另一个呈现状态。
• 由于渲染成本高昂，因此默认情况下，视图不会在所有模型更改时自动刷新。重新折叠仅通过事件发生。_render（） 实际上是一种内部方法。

正交性：

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

连接到后端：

• 所有模块都使用相同的全局后端适配器。模块从不单独与后端通信。这使您的前端后端不可知。

递归：

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

可测试：

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

如果有人知道这些路线的其他框架，请分享！

我们的Web应用程序完全基于此架构，并且自去年年底以来一直在生产中。您可以在 http://beebole.com

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

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