首先,我看不出有一个中心对象来保存你的项目有什么问题,毕竟,注入器是一个单一的,它将你的依赖关系查找到一个中心位置,所以angular确实有一个中心对象,它只是隐藏了. Namspacing不一定意味着耦合,如果它正确完成.即使完成后,您也不需要将代码中的每个对象与其他对象松散耦合.此外,无论何时创建独立的JS脚本,都必须将其包装成角度,以便让它们一起玩得很好.
其次,每次声明所有依赖性(特别是缩小)是非常冗长的,因此与可靠的命名空间相比,从可读性的角度来看没有任何好处.
第三,性能提升很小.它迫使我到处使用单身,但如果我需要的话,我可以自己做,而且大多数时候,我不这样做(网络和DOM操作是我的瓶颈,而不是JS对象).
最后,我喜欢“增强的”HTML和自动双向绑定,但我看不出注入如何使其比其他框架处理依赖性的方式更好,因为它甚至不提供动态加载像require.js.我没有看到任何用例,我对自己说“哦,这是比以前更好的地方,我看到”编码时.
您能否向我解释一下这项技术选择给项目带来了哪些好处？
我现在只能看到一个：常规和最佳实践执行.创建一个lib生态系统是一个很大的问题,但是现在我还没有看到它在角度社区中的成果.
统一的,声明性的依赖性解析
JS是动态语言(这是新的,对吧？),它为程序员提供了很多权力,甚至更多的责任.组件可以通过各种方式相互交互,传递各种对象：常规对象,单例,函数等.它们甚至可以使用甚至没有提到的代码块供其他组件使用.
JS从来没有(并且很可能永远不会)以统一的方式声明公共,私有或包(模块)范围,就像其他语言一样(Java,C,C#).当然有一些封装逻辑的方法,但是要求任何新手使用该语言,他根本就不知道如何使用它.
我喜欢DI(不仅在Angular中,而且在一般情况下)是你可以列出你的组件的依赖关系的事实,你不会感到如何构建这种依赖关系.这对我来说非常重要,特别是Angular中的DI允许你解决这两种组件：这些来自框架本身(如$http),或者是自定义组件(比如我最喜欢的eventBus,我用来包装$on event)处理程序).
我经常看一下服务的声明,我只是通过查看依赖关系来了解它的作用以及它是如何做到的！
如果我要构建和/或使用组件本身深处的所有对象,那么我将始终必须彻底分析实现并从各个方面进行检查.如果我在依赖列表中看到localStorage,我知道我正在使用HTML5本地存储来保存一些数据.我不必在代码中查找它.
组件寿命
我们不再需要打扰某些组件的初始化顺序.如果A依赖于B,则当A需要时,DI将确保B准备就绪.
单元测试
在使用DI时,模拟组件有很大帮助.例如,如果您有控制器：功能Ctrl($scope,a,b,c,d),那么您立即知道它依赖于什么.你注入了适当的模拟,你确保所有参与和控制你的控制器的人都是孤立的.如果您在编写测试时遇到麻烦,那么您很可能搞砸了抽象层次或违反了设计原则(直径法,封装法等)
好习惯
是的,您很可能使用命名空间来正确管理对象的生命周期.在需要的地方定义单身人士,并确保没有人搞砸你的私人成员.
但老实说,如果框架可以为你做到,你会需要吗？
在我学习Angular之前,我一直没有使用JS“正确的方法”.这不是我不在乎,我只是没有必要,因为我只是为了一些UI的使用JS,主要基于jquery.
现在它与众不同,我得到了一个很好的框架,这使我有点跟上良好的实践,但它也给了我很大的力量来扩展它并利用JS所拥有的最好的功能.
当然,糟糕的程序员仍然可以打破最好的工具,但是从我最近读到的D.克罗克福德的“JS the good parts”中学到的东西,人们正在用它做出令人讨厌的东西.感谢jQuery,Angular和其他很棒的工具,我们现在有了一些很好的工具,可以帮助编写优秀的JS应用程序并坚持最佳实践.
结论
正如您所指出的,您至少可以通过执行以下三项操作来编写好的JS应用程序：
>命名空间 – 这可以避免向全局命名空间添加内容,避免潜在的冲突,并允许在需要时轻松解析适当的组件
>创建可重用的组件/模块 – 例如,使用功能模块模式并明确声明私有和公共成员
>管理组件之间的依赖关系 – 通过定义单例,允许从某些“注册表”检索依赖关系,在某些条件不满足时不允许执行某些操作
Angular只是这样做：
>使用$injector来管理组件之间的依赖关系并在需要时检索它们>强制使用同时具有PRIVATE和PUBLIC API的工厂函数.>让组件直接相互通信(通过相互依赖)或共享$scope链.
