4

编辑，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 正确转换，内容的顺序并不重要

页面生成过程将包括以下阶段：

  1. 预处理：初始化模块，处理 GPCS 数据，应用默认 [XML] 模板
  2. 处理/生成：业务逻辑的主要部分，使用最大数据生成臃肿的 XML（尽管希望优化为不生成压载物）
  3. 处理：一些额外的业务逻辑，例如削减一些标记，准备转换，报告，统计等。
  4. 后处理：通过转换引擎（很可能只是 XSLT）解析 XML，输出。

生成的内容将包含大量元数据（例如标签、权限、重要性、必要性、目标输出类型），这些元数据将在后处理期间被剥离。

所以，我的问题是：除了速度，这个解决方案的缺点是什么？在框架的开发/维护及其应用程序中，哪里可能出错？这种架构的缺点是什么？

4

5 回答 5

3

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

于 2008-10-09T19:18:55.753 回答
2

我也不确定向您建议什么“灵活框架”。这一切都取决于你喜欢什么和你的个人品味。

我知道的一件事是，它乍一看可能多么吸引人，那就是远离 XSLT。用 XSLT 做 Hello World 类型的东西和简单的例子非常简单。但是，使用 XSLT，更复杂的项目变得完全无法管理（更不用说不可读了）。我的经验是它给项目带来了巨大的压力。

于 2008-10-09T21:08:46.517 回答
1

我认为您正在寻找一个非常复杂的解决方案。简单地设计和构建您将使用的模式是一项重大工作。如果您的项目总共涉及超过 5-6 人，您可能需要进行有组织的架构设计工作。我想这是你意识到的一点。

我质疑并可能对前端 PHP 的选择提出质疑。我还认为您在很大程度上错误地决定了 XML。

这是我所做的：

  1. 使用 Grails.org 构建服务层
  2. 保持所有可以 RESTFUL 的资源处于静止状态
  3. 使用 Grails 中的 X-fire 插件构建任何需要构建的 SOAP 服务
  4. 利用 Grails 的 GORM 和 RAD 功能来缩短开发时间。
  5. 以 X 或 Y 语言或平台构建客户端以使用这些服务。

我肯定想要纯 Java 的速度来完成我所有的 XML 翻译/处理。如果您有大型文档，则处理这些文档将花费大量时间。

你比任何人都更了解环境的力量，但我会提醒你先做最简单的事情，而不是过度架构。

于 2008-10-09T19:28:11.697 回答
1

您所描述的可能使用tox来实现。它使用混合MVC-ARS架构。我看到的障碍是成本点tox由于它对 Oracle 的依赖而呈现。当然，由于它是开源的，您可以将其转换为 Postgresql。

于 2008-10-09T21:24:38.293 回答
-2

我过去曾开发过一些网页游戏，老实说，它们都不需要如此复杂和笨重的东西。

于 2008-10-09T12:55:14.297 回答