界面设计：将 Java 图形序列化为 D3.js [关闭]答案

【问题标题】：Interface Design: Serializing Java Graphics to D3.js [closed]界面设计：将 Java 图形序列化为 D3.js [关闭]
【发布时间】：2014-05-03 22:57:21
【问题描述】：

我目前在工作场所就遗留 Java Swing 应用程序和 d3.js 图的最终输出之间的接口设计进行辩论。当前的应用程序是一个桌面统计探索工具，它使用 Java2d 解析数据并输出图形。该应用程序正在转换为带有 Web 前端的服务器/客户端应用程序。

目前，图形逻辑与 Java2d 代码紧密耦合。虽然从技术上讲是 Wilkonson 的图形语法的实现，但图形树中的每个组件都呈现给一个 java 组件。

我建议重构图形系统以输出图形的结构化规范（json、xml 等），然后可以将其传递给消费者（前端 Web、ipad 等）进行实际解析和渲染。这将使图形结构与实际渲染分离，理论上允许在任何客户端库或渲染格式中使用相同的输出/蓝图，无论是 d3.js、three.js、svg/canvas/webgl，甚至是本机代码。

这对我来说似乎很直观，但我的同事非常反对这个想法。相反，他们建议调整系统以在服务器端生成 d3 javascript 代码，然后客户端将直接使用这些代码。这将需要在每个图形的基础上实现所有图形设置代码（理论上使用一些模板引擎有条件地在结果 html 中包含 js）。我们的结果将直接与 d3 本身相关联。他们说好处是客户端不必做任何事情来呈现图形输出。

我在这里遗漏了什么吗？从长远来看，后一种方法是否更可取？还是我在以前的设计上走在正确的轨道上？在生成 javascript 方法中我应该考虑一些好处吗？或者，我应该如何构建我的论点，以支持序列化的图形规范，以便让更多人参与我的设计？

【问题讨论】：

我已投票结束此问题，因为我认为没有“最佳”答案。您可以用任何一种方式争论（就像您和您的同事所做的那样），而且由于我们不熟悉代码、要求等，我们当然处于更糟糕的位置，甚至无法发表意见。
我不太确定这是真的。我认为可能会有一个客观上更好的设计。并且社区在此类设计方面的经验可能比我或我的团队更多，因此可以帮助引导我们朝着正确的方向（随着时间的推移维护和适应的痛苦更少）。
那么，如果我们遵循同样的逻辑，任何问题“都没有最佳答案”。因此，我们应该关闭所有 SO 问题，并关闭整个站点！ ;) :))) 但是，说真的，这个问题对我来说看起来很完美，实际上很好地反映了我们所经历的日常情况。

标签： java design-patterns interface d3.js

【解决方案1】：

由于我的知识有限，您的解决方案似乎更通用。你不能做你的，然后在本地运行一个客户端并获取 D3 JavaScript 并将其输出到服务器吗？即，以您的方法的初始输出作为中间阶段，依次进行这两项操作。

额外的开发时间可能是他们提出建议的原因，因此您可能必须能够证明这不会花费您太多时间并且会带来额外的好处。

【讨论】：

【解决方案2】：

虽然这两种解决方案确实可行，但我不确定在服务器端生成 D3 图形然后将它们发送到客户端有什么好处。

另一方面，通过这样做，我可以看到这种方法的一些副作用，例如：

即使更强的耦合也无法提高性能 - 可能会导致代码脆弱和意外后果
缺乏灵活性来支持可能利用您的图形数据但不支持 D3 或 Javascript 的其他客户端。

【讨论】：

哇！我会在下一次会议上向我的老板提及这些观点（虽然我的工作与这个问题没有任何关系；但我的老板不是技术型的）。你能“生成”几个听起来更相似的句子吗？ :) 我被“可能导致脆弱的代码和意想不到的后果”迷住了 :)) ;)

【解决方案3】：

所以基本上听起来您正在考虑使用抽象层来简化非 D3 格式的输出。如果是这样的话，那么这个层的价值很大程度上取决于你对这段代码未来的期望。

如果您知道将来要实施非 D3 解决方案，那么将通用“图表”逻辑与特定“D3 图表”逻辑分开是有意义的，因为这两者各自独立运行其他。

另一方面，如果您怀疑有一天您可能会实施非 D3 版本，但没有立即计划，那么我认为 YAGNI（您将不需要它）原则适用。换句话说，您应该编写最适合手头任务的代码（即没有抽象层），然后在实际需要实现非 D3 图表时重构其中一个。

【讨论】：