作者:魍魉之波_414 | 来源:互联网 | 2023-10-10 00:54
显然,没有一种解决方案可以满足每个人的需求;建筑始终是一种权衡.我想创建一个最初针对网络游戏RAD的框架.目标语言是PHP,尽管该架构应该广泛适用.我对这个框架的目标是:灵活的方式
显然,没有一种解决方案可以满足每个人的需求;建筑始终是一种权衡.我想创建一个最初针对网络游戏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管理起来可能很庞大,并且本质上增加了开发人员必须使用的额外编程语言(至少如果我正确理解您的描述).我的经验是相对较少的人知道它,甚至更少的人可以做到他们想要的.