显然,没有一种解决方案可以满足每个人的需求;建筑始终是一种权衡.我想创建一个最初针对网络游戏RAD的框架.目标语言是PHP,尽管该架构应该广泛适用.

我对这个框架的目标是：灵活的方式,你可以达到结果;开发人员的最大舒适度;连接模块,如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(尽管希望优化不生成balast)
>处理：一些额外的业务逻辑,例如减少一些标记,准备转换,报告,统计等
>后处理：通过转换引擎(很可能只是XSLT)解析XML,输出.

将使用许多元数据(例如标签,许可,重要性,必要性,目标输出类型)生成内容,这些元数据将在后处理期间被剥离.

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

解决方法:

XSLT管理起来可能很庞大,并且本质上增加了开发人员必须使用的额外编程语言(至少如果我正确理解您的描述).我的经验是相对较少的人知道它,甚至更少的人可以做到他们想要的.