依赖注入的3种方式 Service层和Dao层真的有必要每个类都加上接口吗？
Service层和Dao层真的有必要每个类都加上接口吗？
这主要取决于您的项目：
例如，如果项目中使用了hibernate，以后可能会切换到mybatis，那么Dao需要使用这个接口。这不会影响上层代码的更改。
另一个例子是，项目是一个单一的应用程序。任何代码修改都需要重新编译整个项目，因此不需要接口。如果项目是由模块编译和部署的，那么可以使用接口解耦。假设修改了Dao，只需要重新编译和部署Dao模块，而不影响上层模块。
此外，如果项目团队中有许多新手，简单的代码结构可能更合适。复杂项目结构的学习成本较高。
如果工程进度非常紧迫，我们可以用简单粗暴的方式用经济成本来说明原因。
使用接口的成本是不使用接口的成本（包括后续维护成本）。
如果项目变化很大，部署了模块，项目不急，使用接口的成本比不使用接口的成本低，虽然早期不使用接口似乎更简单；相反，不使用接口的成本低，而且连框架都不能用～
毕竟工具是提高效率的，那你为什么不能和自己相处呢
自动注入到底比new好在哪？
控制反转和容器IOC只能看作是一种编程思想。在理想状态下，可以实现自动注射和生命周期管理。但是，在实际的发展中，我个人觉得有时不如新的方便。我主要遇到以下问题：
1。编写大量的配置和构造函数比编写新的更麻烦，特别是对于某些函数，项目只使用一次。原来，new会立即完成，但是如果你想使用依赖注入，你仍然需要编写配置
2。当需要注入更多的类时，构造函数就像老妇人的裹尸布一样臭，一样长。关键是以前用过的一些类现在不用了，你要手动清理构造函数，这比new要麻烦多了
3。这也是最关键的一点，有时项目的复杂性很复杂，会遇到循环注入的问题。也就是说，A依赖B，B依赖C，C依赖A，这种情况说明架构的存在是不合理的。在这一点上，您可以重构系统，也可以不直接使用依赖注入来解决它。]总之，依赖注入只是一种编程思想，具有一些高级特性。它不是万能的。它存在的意义是脱钩。从宏观上讲，就是要解决多人共同开发一个项目时，各自独立的模块，减少相互之间的依赖和干扰。从微观的角度看，有几个类是密切相关的。虽然文件是独立的，但是功能是集成的。在这个时候，脱钩是没有意义的。为什么不是新的？
因此，我个人理解依赖注入与引擎是一样的。发动机由几个主要部件组成。这些组件之间是解耦的，可以通过依赖注入来实现。对于单个组件的内部部件和螺钉，必须使用依赖注入来实现它们。这比收益多一点。使用new来实现它们要方便得多。。。[挑鼻子][挑鼻子][挑鼻子][挑鼻子][挑鼻子]
依赖注入的3种方式 如何将xposed模块注入系统 di依赖注入三种方式
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
