编辑,2020/09:如果有人想知道,12 年后,是的,我们现在都已经迁移到 JSON 和 Kubernetes。原文如下。
显然,没有一种单一的解决方案可以满足每个人的需求。架构始终是一种权衡。我想创建一个框架,最初是针对网页游戏的RAD。目标语言是 PHP,尽管该架构应该是广泛适用的。
我为这个框架设定的目标是:实现结果的方式的灵活性;为开发人员提供最大的舒适度;连接乐高®积木等模块;多种输入,多种输出,一种处理格式。
不优先的目标是速度、企业使用和赚钱。它应该是一个开源项目。
这种设计的基石是所有内容,在转换之前,都在 XML 中处理(基于我使用过的 EAI 系统,eGate 的想法)。数据抽象层——希望是一些智能的 ORM——现在并不重要。输出将使用 XSLT 或任何其他自定义模块生成,几乎适用于任何客户端 - 用于旧浏览器的 HTML、用于现代浏览器的 XHTML/HTML5、用于移动客户端的简单 HTML、用于 AJAX/XMLRPC 的 XML 等。
使用 XML 的主要原因是:
- 这是一个众所周知的标准
- 用于导航和修改内容的现有工具,如 XPath、SimpleXML 和 DOM
- XSLT 提供了一种强大而统一的方法来将代码转换为任何标签汤
- 我发现 XML 标记非常容易阅读,因此我不认为 JSON 或 YAML 的优势在这里有所作为
- 内容可以轻松堆叠,只要使用 XSLT 正确转换,内容的顺序并不重要
页面生成过程将包括以下阶段:
- 预处理:初始化模块,处理 GPCS 数据,应用默认 [XML] 模板
- 处理/生成:业务逻辑的主要部分,使用最大数据生成臃肿的 XML(尽管希望优化为不生成压载物)
- 处理:一些额外的业务逻辑,例如削减一些标记,准备转换,报告,统计等。
- 后处理:通过转换引擎(很可能只是 XSLT)解析 XML,输出。
生成的内容将包含大量元数据(例如标签、权限、重要性、必要性、目标输出类型),这些元数据将在后处理期间被剥离。
所以,我的问题是:除了速度,这个解决方案的缺点是什么?在框架的开发/维护及其应用程序中,哪里可能出错?这种架构的缺点是什么?