extjs“iframe架构”的缺点(我应该重构为MVC模式吗?

Downside to extjs "iframe architecture" (should I refactor to MVC pattern?)

本文关键字：重构 MVC 模式 我应该 iframe 架构 缺点 extjs      更新时间：2023-09-26

我有一个现有的内部网Web应用程序（仅内部）使用"iframe架构"使用ExtJS构建，即它在索引页面上有一个顶部菜单和一个选项卡面板，以及大约30个其他单独的网页，这些网页在主选项卡面板内作为iframe"选项卡"打开。

使用

iframes没有任何特别的理由，所有内容都在同一个域上，并且大多数其他单独的页面都是使用ExtJS库编写的，几乎完全是用javascript编写的。几乎所有的html都由空的HTML，HEAD和BODY标签组成。

我真的很想使用 ExtJS MVC 架构重构它并放弃 iframe，但由于"一切正常"，我无法证明花时间这样做是合理的。

我有一个想法，但无法测试是：这些单独的页面中的每一个都有自己的Ext.onReady事件和视口等，这个 web 应用程序必须为它打开的每个 iframe 选项卡加载完整的 ExtJS 框架，严重放大客户端资源使用。谁能确认这种类型的架构会用 ExtJS 框架做到这一点？

还有其他非常可靠的理由应该重构吗？

或者，重构到 MVC 架构只会让我更轻松地维护代码而没有性能提升吗？（因为目前一切都按预期工作）

不幸的是，

我没有类似于您手边的项目，所以我无法自己测试它，但这是我的 2c... :)

  1. 我确实认为每个页面都会启动自己的 ExtJs 框架副本，但我认为它只影响 CPU 和内存使用率。网络流量不应该有太大的不同，因为核心 ExtJs 文件将被缓存。

  2. 我建议在运行此应用程序时检查网络流量，因为您将看到浏览器如何处理所有这些。您可能希望在核心 ExtJs 函数中添加一些额外的逻辑，以确认框架是否确实被实例化了几次。

  3. 如果最终用户遇到一些性能问题 - 证明重构可能是很好的一点。否则就有点难了。当然，除非您有一些计划在不久的将来扩展功能并计划继续开发此应用程序。

相关文章：