architecture - 最灵活的 Web 开发框架架构？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




编辑，2020/09:如果有人想知道，12 年后，是的，我们现在都已经转向 JSON 和 Kubernetes。原文如下。
显然，没有一种解决方案可以满足所有人的需求。架构总是一种权衡。我想创建一个框架，最初是针对网页游戏的RAD。目标语言是 PHP，虽然架构应该是广泛适用的。
我为这个框架制定的目标是:实现结果的方式的灵 active ；为开发人员提供最大的舒适度；连接模块，如 LEGO® 积木；多种类型的输入，多种类型的输出，一种处理格式。
不是优先考虑的目标是速度、企业使用和赚钱。它应该是一个开源项目。
这种设计的基石是所有内容在转换之前都以 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，输出。

内容将使用大量元数据(例如标签、权限、重要性、必要性、目标输出类型)生成，这些元数据将在后期处理过程中被剥离。
所以，我的问题是:除了速度之外，这个解决方案的缺点是什么？在框架及其应用程序的开发/维护过程中可能会出错的地方？这种架构的缺点是什么？

Answer 1

XSLT 管理起来可能很笨重，并且本质上增加了开发人员必须使用的额外编程语言(至少如果我正确理解了您的描述)。我的经验是，知道它的人相对较少，能够让它为所欲为的人更少。