在Java中，IoC / DI是一种非常常见的实践，广泛应用于web应用程序、几乎所有可用的框架和Java EE中。另一方面，也有很多大型的Python web应用程序，但除了Zope(我听说它的编码真的很糟糕)之外，IoC在Python世界中似乎并不常见。(如果你认为我是错的，请举一些例子)。
当然，有一些流行的Java IoC框架的克隆可用于Python，例如springpython。但它们似乎都没有被实际使用。至少，我从来没有碰到过Django或sqlalchemy+<插入您最喜欢的wsgi工具箱在这里>的基于web应用程序使用类似的东西。
在我看来，IoC有合理的优势，可以很容易地取代django-default-user-model，但在Python中广泛使用接口类和IoC看起来有点奇怪，而且不»pythonic«。但是也许有人有更好的解释，为什么IoC在Python中没有被广泛使用。
当前回答
IoC和DI在成熟的Python代码中非常常见。由于鸭子类型，您不需要框架来实现依赖注入。
最好的例子是如何使用settings.py设置Django应用程序:
# settings.py
CACHES = {
'default': {
'BACKEND': 'django_redis.cache.RedisCache',
'LOCATION': REDIS_URL + '/1',
},
'local': {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
'LOCATION': 'snowflake',
}
}
Django Rest Framework充分利用了DI:
class FooView(APIView):
# The "injected" dependencies:
permission_classes = (IsAuthenticated, )
throttle_classes = (ScopedRateThrottle, )
parser_classes = (parsers.FormParser, parsers.JSONParser, parsers.MultiPartParser)
renderer_classes = (renderers.JSONRenderer,)
def get(self, request, *args, **kwargs):
pass
def post(self, request, *args, **kwargs):
pass
让我提醒一下(来源):
“依赖注入”是一个5美分概念的25美元术语。[…依赖注入意味着给一个对象它的实例变量。[…]。
其他回答
IoC和DI在成熟的Python代码中非常常见。由于鸭子类型，您不需要框架来实现依赖注入。
最好的例子是如何使用settings.py设置Django应用程序:
# settings.py
CACHES = {
'default': {
'BACKEND': 'django_redis.cache.RedisCache',
'LOCATION': REDIS_URL + '/1',
},
'local': {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
'LOCATION': 'snowflake',
}
}
Django Rest Framework充分利用了DI:
class FooView(APIView):
# The "injected" dependencies:
permission_classes = (IsAuthenticated, )
throttle_classes = (ScopedRateThrottle, )
parser_classes = (parsers.FormParser, parsers.JSONParser, parsers.MultiPartParser)
renderer_classes = (renderers.JSONRenderer,)
def get(self, request, *args, **kwargs):
pass
def post(self, request, *args, **kwargs):
pass
让我提醒一下(来源):
“依赖注入”是一个5美分概念的25美元术语。[…依赖注入意味着给一个对象它的实例变量。[…]。
我同意@Jorg的观点，在Python中DI/IoC是可能的，更简单，甚至更漂亮。缺少的是支持它的框架，但也有一些例外。举几个我想到的例子:
Django注释允许您将自己的Comment类与自定义逻辑和表单连接起来。(更多信息) Django允许你使用一个自定义Profile对象来附加到你的User模型。这不是完全的IoC，但却是一个很好的方法。就我个人而言，我希望像注释框架那样取代hole User模型。(更多信息)
在我看来，像依赖注入这样的事情是僵化和过于复杂的框架的症状。当代码主体变得过于沉重而难以更改时，你会发现自己不得不选择其中的一小部分，为它们定义接口，然后允许人们通过插入这些接口的对象来改变行为。这很好，但最好在一开始就避免这种复杂性。
这也是静态类型语言的症状。当您必须表达抽象的唯一工具是继承时，那么您几乎到处都在使用继承。话虽如此，c++与之非常相似，但从未像Java开发人员那样对构建器和接口着迷。人们很容易以编写太多泛型代码为代价，实现灵活和可扩展的梦想，而这些代码几乎没有真正的好处。我认为这是文化问题。
通常我认为Python人习惯于为工作选择正确的工具，这是一个连贯而简单的整体，而不是一个真正的工具(带有一千种可能的插件)，它可以做任何事情，但提供了令人眼花缭乱的可能配置排列。在必要的地方仍然有可互换的部分，但由于duck-typing的灵活性和语言的相对简单性，不需要定义固定接口的大形式主义。
IoC容器主要使用**kwarg来“模仿”
class A:
def __init__(self, **kwargs):
print(kwargs)
Class B:
pass
Class C:
pass
Ainstance = A(b=B, c=C)
不像Java中的强类型。Python的duck类型行为使得传递对象非常容易。
Java开发人员专注于构造类结构和对象之间的关系，同时保持灵活性。IoC对于实现这一目标非常重要。
Python开发人员专注于完成工作。他们只是在需要的时候把类连接起来。他们甚至不用担心课程的类型。只要它会嘎嘎叫，它就是鸭子!这种性质没有给国际奥委会留下任何余地。
