接口设计：将Java图形序列化到D3.js

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

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

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

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

---

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

鉴于我的知识有限，您的解决方案似乎更通用。 难道你不能做你的，然后在本地运行一个客户端，获取D3JavaScript并将其输出到服务器吗？也就是说，两种方法都是串联进行的，将方法的初始输出作为中间阶段

---

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

虽然这两种解决方案都确实可行，但我不确定在服务器端生成D3图形，然后将其发送到客户端是否有任何好处

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

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

---

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

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

---

另一方面，如果你怀疑有一天你可能会实现一个非D3版本，但是没有立即的计划，那么我认为YAGNI（你不会需要它）原则适用。换句话说，你应该为手头的任务编写最好的代码（即没有抽象层），然后在实际需要实现非D3图表时重构一个。我投票结束这个问题，因为我认为没有“最佳”答案。你可以用任何一种方式争论（正如你和你的同事所做的那样），我们当然处于更糟糕的地位，甚至无法发表意见，因为我们不熟悉代码、要求等。我不太确定这是真的。我认为客观上可能有更好的设计。社区可能比我或我的团队对此类设计有更多的经验，因此可以帮助我们朝着正确的方向（随着时间的推移，维护和适应的痛苦更少）前进。然后，如果我们遵循同样的逻辑，任何问题“都没有最好的答案”。所以，我们应该关闭所有So问题，并关闭完整的站点！；）：）但是，说真的，这个问题在我看来很完美，实际上很好地反映了我们所经历的日常情况。哇！我将在下次会议上向我的老板提及这些要点（虽然我的工作与这个问题无关；但我的老板不是技术型的）。你能“生成”两个听起来更相似的句子吗我被“可能导致脆弱的代码和意外后果”迷住了：；）