AngularJS依赖注射有什么好处？ [英] What are the benefits of AngularJS dependancy injection?

问题描述

现在我已经有一段时间的工作了，我看不出我以前的编码方式有什么改进。

首先，我可以看到有一个中心对象持有你的项目是什么问题，毕竟注射器是一个单身人士，将你的依赖关系看成一个中心位置，所以角度确实有一个中心对象，它只是被隐藏。如果它正确完成，Namspacing不一定意味着耦合。即使完成了，你也不需要你的代码的每一个对象与其他代码松散耦合。此外，任何时候你创建一个独立的JS脚本，你必须把它包装成有角度，使他们一起玩得很好。

其次，每次都宣布你的所有依赖（特别是缩小），所以与适当的命名空间相比，可读性的观点没有任何增益。

第三，性能提升最小。它迫使我在任何地方使用单身人士，但如果我需要，我可以自己做这个，大多数时候，我不（网络和DOM操纵是我的瓶颈，而不是JS对象）。

最后，我喜欢增强的HTML和自动双向绑定，但是我看不到如何注入使其比其他框架处理依赖的方式更好因为它甚至不能提供像require.js这样的动态加载。我没有看到任何使用情况，我对自己说，哦，这是比以前好多了，我看到编码。

你能解释一下给我这个技术选择给项目带来什么好处？

我现在只能看到一个：惯例和最佳实践执法。创建一个lib生态系统是一个很大的工作，但是现在我在角色社区看不到它的成果。

解决方案

p> 对于我，Angular的依赖注入改善了我的项目的几个方面，我将在这里列出。我希望这将向您展示OTHERS如何从中受益，但如果您的组织和经验丰富的JS开发人员，那么也许您可能不一样。我认为在某些时候，这只是开发自己的工具和编码指南的问题。

统一的声明依赖解析

是一种动态语言（这是新的，嗯？），它给程序员带来了很多的权力，甚至更多的责任。组件可以通过传递各种对象：常规对象，单例，函数等，以各种方式相互交互。甚至可以使用甚至不被其他组件使用的代码块。

JS从来没有（并且很可能永远不会）声明像其他语言（Java，C，C＃）的公共，私有或包（模块）范围的统一方式。当然有一些封装逻辑的方式，但要求任何一个新来的语言，他根本不知道如何使用它。

我喜欢DI不仅在Angular中，而且在一般情况下）是您可以列出对组件的依赖性的事实，并且您不会担心如何构建此依赖关系。这对我来说非常重要，特别是在Angular中，DI允许您解析两种组件：框架本身（如 $ http ）或自定义组件我最喜欢的 eventBus ，我用来包裹 $ on 事件处理程序）。

很多时候我会看一下服务的声明，我知道它的功能，以及它是如何看待依赖关系的！

如果我是构建和/或利用组件本身深处的所有对象，然后我总是必须从各个方面彻底分析实现。如果我在依赖关系列表中看到 localStorage ，我知道我正在使用HTML5本地存储来保存一些数据。我不需要在代码中找到它。

组件的使用寿命

我们不需要再麻烦某些组件的初始化顺序。如果 A 依赖于 B 则DI将确保 B 在 A 需要它时就已经准备好了。

单元测试

当您使用DI时，它有助于嘲笑组件。例如，如果您有控制器：函数Ctrl（$ scope，a，b，c，d）然后立即知道它取决于什么。你注入适当的嘲笑，你确保所有方面谈话和听控制器是孤立的。如果你有麻烦写作测试，那么你最有可能搞砸抽象层面或者违反设计原则（Diameter，封装等）。

良好的习惯

是的，很可能您可以使用命名空间来正确管理对象的使用寿命。确定需要的单身人士，并确保没有人混淆您的私人会员。
但是老实说，如果框架可以为你做，你会需要吗？
我没有使用JS正确的方式，直到我学习了Angular。这不是我不在乎，我只是没有，因为我使用JS只是一些tweeks的UI，主要基于jquery。

现在它的不同的是，我有一个很好的框架，迫使我跟上良好的做法，但它也给了我很大的力量来扩展它，并利用JS的最佳功能。

当然，糟糕的程序员仍然可以打破最好的工具，但是从最近阅读的JS好的部分中我学到了什么。克罗克福德的人们正在做一些重要的讨厌的事情。感谢jQuery，Angular等工具，我们现在有一些很好的工具，可以帮助编写好的JS应用程序，并遵守最佳实践。

结论

正如您所指出的，您可以通过至少做以下三件事情来编写好JS应用程序：

1. 命名空间 - 这样做避免了将全局命名空间添加到全局命名空间中，避免了潜在的冲突，并允许在需要时轻松解决正确的组件。


2. 创建可重用的组件/模块 - 例如使用功能模块模式并明确声明私有和公共成员


3. 管理组件之间的依赖关系 - 通过定义单例，允许从某些注册表检索依赖关系，在某些条件不允许时禁止执行某些操作满足

Angular只是这样做：

• 具有管理d的 $ inject 组件之间的历史记录，并在需要时检索它们


• 强制使用具有PRIVATE和PUBLIC API的工厂函数。


• 让组件彼此通话直接（通过彼此依赖）或共享的 $ scope 链。

I have been working with angular for some times now, and I fail to see how it is an improvement from my previous way of coding.

First, I can't see what's wrong with having a central object to hold your project, after all, the injector is a singleton that looks up your dependancies into a central place, so angular does have a central object, it's just hidden. Namspacing doesn't necesally means coupling, if it's done properly. En even when it's done, you don't need every single object of your code to be loosely coupled with the others. Besides, anytime you create a standalone JS script, you have to wrap it into angular so make them play nice together.

Second, It's very verbose to declare all your dependancies everytime (espacially with minification), so there is no gain from the readability point of view compared to proper namespacing.

Third, the performance gain is minimal. It forces me to use singletons everywhere, but I can do that on my own if I need to, and most of the time, I don't (network and DOM manipulations are my bottle neck, not JS objects).

In the end, I like the "enhanced" HTML and the automatic two way bindings, but I can't see how the injection make it any better than the way other frameworks deal with dependancies, given that it doesn't even provide dynamic loading like require.js. I haven't see any use case where I say to myself "oh, this is where it so much better than before, I see" while coding.

Could you explain to me what benefits does this technical choice brings to a project ?

I can see only one for now : convention and best practice enforcement. It's a big one to create a lib ecosystem, but for now I don't see the fruit of it in the angular community.

解决方案

For me there are few aspects of how Angular's dependency injection is improving my projects, which I will list here. I hope that this will show you how OTHERS can benefit from it, but if you are well organised and experienced JS developer, then perhaps it might not be the same case for you. I think at some point this is just the matter of developing your own tools and coding guide.

Unified, declarative dependency resolving

JS is dynamic language (that's new, huh?) which gives a lot of power and even more responsibility to the programmer. Components can interact with each other on various ways by passing around all sorts of objects: regular objects, singletons, functions, etc. They can even make use of blocks of code which were not even mentioned to be used by other components.

JS has never had (and most likely never will) a unified way of declaring public, private or package (module) scopes like other languages have (Java, C, C#). Of course there are ways of encapsulating logic, but ask any newcomer to the language and he will simply don't know how to use it.

What I like about DI (not only in Angular, but in general) is the fact that you can list dependencies to your component, and you are not troubled how this dependency got constructed. This is very important for me, especially that DI in Angular allows you to resolve both kinds of components: these from the framework itself (like $http), or custom ones (like my favorite eventBus which I'm using to wrap $on event handlers).

Very often I look at the declaration of a service and I know what it does and how it does it just by looking at dependencies!

If I was to construct and/or make use of all those objects deep in the component itself, then I would always have to analyze implementation thoroughly and check it from various aspects. If I see localStorage in dependencies list, I know for the fact that I'm using HTML5 local storage to save some data. I don't have to look for it in the code.

Lifespan of components

We don't need to bother anymore about order of initialization of certain components. If A is dependent on B then DI will make sure that B is ready when A needs it.

Unit testing

It helps a lot to mock out components when you are using DI. For instance, if you have controller: function Ctrl($scope, a, b, c, d) then you instantly know what it is dependent on. You inject proper mocks, and you are making sure that all parties talking and listening to your controller are isolated. If you have troubles writing tests then you most likely messed up levels of abstraction or are violating design principles (Law Of Diameter, Encapsulation, etc.)

Good habits

Yes, most likely you could use namespacing to properly manage the lifespan of your objects. Define singleton where its needed and make sure that noone messes up your private members. But honestly, would you need that if the framework can do it for you? I haven't been using JS "the right way" just until I learned Angular. It's not that I didn't care, I just didn't have to since I was using JS just for some tweeks of UI, primarly based on jquery.

Now its different, I got a nice framework which forces me a bit to keep up with good practices, but it also gives me great power to extend it and make use of the best features that JS has.

Of course poor programmers can still break even the best tool, but from what I've learned by recently reading "JS the good parts" by D. Crockford people were doing reeeeeealy nasty stuff with it. Thanks to great tools like jQuery, Angular and others we now have some nice tool which helps to write good JS applications and sticking to best practices while doing so.

Conclusion

As you have pointed out, you CAN write good JS applications by doing at least those three things:

1. Namespacing - this avoids adding stuff to global namespace, avoids potential conflicts and allows for resolving proper components easily where needed
2. Creating reusable components / modules - by, for instance, using function module pattern and explicitly declaring private and public members
3. Managing dependencies between components - by defining singletons, allowing for retrieving dependencies from some 'registry', disallowing of doing certain stuff when certain conditions are not meet

Angular simply does that by:

• Having $injector which manages dependencies between components and retrieves them when needed
• Forcing to use factory function which has both PRIVATE and PUBLIC APIs.
• Let the components talk to each other either directly (by being dependent of one another) or by shared $scope chain.

这篇关于AngularJS依赖注射有什么好处？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！