架构模式是对开放/封闭原则的极端违反[关闭]

Question

我正在开发一个 Web 应用程序，它会在给定一组有限参数的情况下自动生成 Bootstrap 站点。我需要有关架构决策的帮助，因为随着时间的推移，我做出了非常幼稚的设计决策，我不想在这个项目中重复这个错误。对于我的 PoC，我采用 MVC 方法进行设计，顶层架构（见上文）包含以下内容：

• CanvasComponent - 这是应用程序的入口点，用户可以在其中生成他们的网站并被允许下载的 UI 元素；

• CanvasService - 该服务编排网站的创建，并依赖一组服务（NavbarService、HeroService、FooterService）；

• DomService - 该服务负责创建高级别无样式的 DOM 元素；

• ComponentService - 这组服务（NavbarService、HeroService、FooterService）负责创建较低级别的 DOM 元素；

• FontService - 此服务是 Google 字体库。

以上是我很快整理出来的，所以我知道它并不完美。我也有一些关于项目方向的问题，关于它的可扩展性，因为我正朝着生产化它的方向发展。这些是我的问题：

1. 我向某人展示了它，他们说他们无法理解它......因为听起来我的 CanvasService、DomService 和组件服务创建了原始 HTML，所有这些都是描述 DOM 元素的模型。它似乎设计不当。我们开发服务的方式不可扩展或不可管理。如果不出意外，这是对开放/封闭原则的极端违反。它们最终将是巨大的“工厂”，不能完全覆盖 DOM 元素的所有功能。 这是我最关心的问题。如何从架构的角度解决这个问题？

2. 鉴于项目的性质，我正在广泛处理原始 html。我使用多种方法来动态生成所需的 HTML。我想问一下以上是否可取。在架构上创建和管理 HTML 块的最简洁的方法是什么？我应该使用原始字符串还是创建更定制的东西？

3. 为每个组件（导航栏、英雄、页脚）存储各种样式然后随机应用它们的最佳方法是什么？据我了解，风格可以分为两类——模板和主题。一个模板可以有多个主题，一个主题可以关联多个主题。一个很好的例子是网站上的“浅色/深色”颜色模式。目前在 NavbarService 中，我将一系列可能的宽度和高度存储在一个数组中。

4. 除了违反开放封闭原则（未知未知）之外，我目前的架构方法是否还会出现任何问题？过去，每当我开始这样的项目时，它们很快就会变得不可持续。我失去了兴趣，因为那时我正在与代码库搏斗。我希望这个过程继续令人愉快，并在项目过程中保持我的代码干净和可管理，并应用最佳原则。

此处提供示例演示：https://stackblitz.com/edit/angular-ivy-2pga8q（每次重新加载页面时，都会出现一个新的导航栏）。

Answer 1

这是一个有趣的问题。我也不太了解图表，但您的描述更有意义。

让我们假设您生成的 HTML/CSS/JS 组件经过合理编写，并生成了格式合理且合理的输出。此时，您实际上并不“需要”存储有关它的元数据，因为任何东西都将是不必要的膨胀。您需要的是能够构建小的模块化代码块，这些代码块可以在编辑或附加输入参数后再次重新编译。

为了支持这一点，我强烈建议将代码 (HTML) 的输出分离为带有版本标记的解决方案库 - 生成的代码应该是来自用户或数据输入的标记数据的集合。

为了创建一个简单的类比，想象一下公式 (8+1+1=10)。

在此示例中，输出 (10) 是您唯一需要发布/呈现/存储的内容。但是，您需要保持起始数据 (8+1+1) 的独立性 - 主要是因为如果其中一个值发生变化（例如现在是 8+2+1），您现在可以使用新的输出重新生成第二个版本版本并获得新答案 (11)。

因此，我更关注存储构建块/所见即所得/标记组件，而不是担心输出元素的字符串/文本格式。从架构的角度来看，如果您持续需要交互/修改此代码，则需要关注易用性和可重用性。

还请记住，除非您正在创建天网，否则您不是在编写“编写代码的代码”。您正在编写帮助人类编写代码的代码。始终假设需要从外部来源进行干预和修改 - 专注于获取（算法 + 输入 = 输出）的模块化形式并存储过程和输入。如果你做对了，你可以随时以任何理由重新生成输出。