python - 压倒一切的依赖提供者是否被认为是不好的做法?
问题描述
我正在用 D 编程语言重新实现类似 Python Dependency Injector的东西。我想为 D 构建一个纯依赖注入框架。
覆盖提供者是否被认为是不好的做法?似乎覆盖提供者显然是一种非本地依赖关系,而非本地依赖关系通常被 OOP 理论认为是一种不好的做法。
那么我应该还是不应该在 D 的纯依赖注入框架中实现提供者的覆盖?
解决方案
首先,D 中没有标准的 DI 支持。标准我的意思是 - DI 框架不是 D 标准库的一部分。因此,如何实现它完全取决于您。我只是简单地浏览了你提到的 Python Dependency Injector 项目,除了一些特定于 python 的东西之外,我认为没有理由不能以相同的方式完成在 D 中实现的好的 DI 框架。“提供者”这个名字让我想起了 Java SPI 的工作原理,这是我们(我也是一名 Java 开发人员)使用了几十年的方法,并且被证明是一种很好的方法。
您的问题有点令人困惑,因为覆盖在 D 中具有特殊含义。在我看来,您的 DI 框架的用户应该能够插入不同但兼容的提供程序,只要这些提供程序提供相同类型的对象(实现您的班级需要的一些接口)。
我上面说了标准库中没有标准的DI框架,但值得一提的是,D社区的其他成员为D做的DI框架。其中之一是优秀的(类似 Spring)Poodinis 框架:https ://github.com/mbierlee/poodinis 。看看它是否符合您的需求。
推荐阅读
- android - ListView 元素扩展过多
- java - JDK 17 外存 API 引发异常 - 方法引发“java.lang.UnsatisfiedLinkError”异常
- javascript - 尽管使用 200 个响应代码获取静态文件,但 Django 并未设置页面样式
- typescript - 如何使用 VS Code 扩展 API 动态突出显示变量名?
- visual-studio - 如何从 Dacpac for Azure Pipeline CI/CD 中自动排除仅开发表?
- r - 如何将 for 循环中生成的数据组合成一个散点图?
- ssms - Microsoft SQL Server 管理工作室
- html - 如何为 emscripten 制作无边框的 HTML 画布
- openshift - ECS 与 AppDynamics 的集成问题
- jpa - java.lang.RuntimeException:无法从 PreparedStatement 获取 OracleSpatial Connection 对象