阅读了上述帖子后,我仍然无法相信将 Sencha 元数据文件保存在代码存储库中并从元数据生成所有 JavaScript 适合大型项目。
Sencha Architect 的想法是让代码不保存在 javascript 文件中,而是保存在 JSON 元数据中,每当您需要编辑 JavaScript 代码时,您都必须使用 IDE 并编辑元数据。Phil Strong 说:“我们要求您继续使用 Architect 作为您的编辑器,并且使用 Git 或 SVN 与 20 名工程师一起这样做是完全安全的。”。当然,这个工作流程对 Sencha 来说是非常有利可图的,它迫使 20 个人使用授权的 Sencha Architect,因为要更改一行 JavaScript 代码,开发人员必须使用 Sencha Architect。
当两个人编辑同一个文件时,IDE 会更新元数据。然后他们将文件签入代码存储库,其中一个必须解决冲突,因此开发人员必须合并两个元数据文件,而不是 JavaScript 文件。
除非开发人员使用 Sencha Architect,否则不允许开发人员编辑 JavaScript 的整个想法适得其反,因为同一个人可以使用他最喜欢的 IDE 同时进行 Java 和 JavaScript 开发,或者 Python 和 JavaScript。在同一个 IDE 中进行客户端和服务器编程比在两个 IDE 之间切换要快。一个大项目的现实是,您在全球有多个团队使用不同的 IDE,您也可能有一个由承包商实施的短期项目,他也拥有他最喜欢的 IDE。
ExtJS 是一个设计良好的框架,你不需要 SenchaArchitect 来修改一行 JavaScript 代码。
使用 JavaScript 编码时,我保存我的 JavaScript 文件并刷新浏览器,然后立即查看更改。Sencha Archtect 增加了一个额外的步骤,它需要你发布 javascript(从元数据生成 JavaScript),并且项目越大,延迟越长。通常我必须在生产中修改 JavaScript 文件,有时更改一行可以解决问题,再次,我必须使用 Sencha Architect 从元数据重新生成这一行。
我只使用 Sencha Architect 进行快速原型设计,然后将生成的文件签入代码存储库并继续手动编辑 JavaScript。通过这种方法,我可以使用版本控制系统来查看 JavaScript 的历史。如果我将 JSON 元数据签入到 VCS 中,那么我将没有 JavaScript 的历史记录,我将拥有违反直觉的 JSON 元数据的历史记录。
我认为拥有 GUI 表单的元数据是可以的,但是 MVC 控制器级别也必须从元数据生成的限制是不行的。