我发现我的构造函数开始是这样的:
public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )
随着参数列表的不断增加。既然“容器”是我的依赖注入容器,为什么我不能这样做:
public MyClass(Container con)
每一节课?缺点是什么?如果我这样做,感觉就像我在使用美化的静电。请分享你对IoC和依赖注入疯狂的想法。
我发现我的构造函数开始是这样的:
public MyClass(Container con, SomeClass1 obj1, SomeClass2, obj2.... )
随着参数列表的不断增加。既然“容器”是我的依赖注入容器,为什么我不能这样做:
public MyClass(Container con)
每一节课?缺点是什么?如果我这样做,感觉就像我在使用美化的静电。请分享你对IoC和依赖注入疯狂的想法。
当前回答
这就是我使用的方法
public class Hero
{
[Inject]
private IInventory Inventory { get; set; }
[Inject]
private IArmour Armour { get; set; }
[Inject]
protected IWeapon Weapon { get; set; }
[Inject]
private IAction Jump { get; set; }
[Inject]
private IInstanceProvider InstanceProvider { get; set; }
}
下面是如何执行注入和在注入值后运行构造函数的粗略方法。这是一个功能齐全的程序。
public class InjectAttribute : Attribute
{
}
public class TestClass
{
[Inject]
private SomeDependency sd { get; set; }
public TestClass()
{
Console.WriteLine("ctor");
Console.WriteLine(sd);
}
}
public class SomeDependency
{
}
class Program
{
static void Main(string[] args)
{
object tc = FormatterServices.GetUninitializedObject(typeof(TestClass));
// Get all properties with inject tag
List<PropertyInfo> pi = typeof(TestClass)
.GetProperties(BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public)
.Where(info => info.GetCustomAttributes(typeof(InjectAttribute), false).Length > 0).ToList();
// We now happen to know there's only one dependency so we take a shortcut just for the sake of this example and just set value to it without inspecting it
pi[0].SetValue(tc, new SomeDependency(), null);
// Find the right constructor and Invoke it.
ConstructorInfo ci = typeof(TestClass).GetConstructors()[0];
ci.Invoke(tc, null);
}
}
我目前正在做一个类似这样的爱好项目 https://github.com/Jokine/ToolProject/tree/Core
其他回答
你在使用什么依赖注入框架?你尝试过使用基于setter的注入吗?
基于构造函数的注入的好处是,对于不使用依赖注入框架的Java程序员来说,它看起来很自然。你需要5个东西来初始化一个类,然后你的构造函数有5个参数。缺点正如你所注意到的,当你有很多依赖时,它会变得笨拙。
在Spring中,你可以使用setter来传递所需的值,并且可以使用@required注释来强制注入这些值。缺点是您需要将初始化代码从构造函数移动到另一个方法,并在所有依赖项注入后通过使用@PostConstruct进行标记让Spring调用该方法。我不确定其他框架,但我认为它们做了类似的事情。
两种方法都有效,这是一个偏好的问题。
这就是我使用的方法
public class Hero
{
[Inject]
private IInventory Inventory { get; set; }
[Inject]
private IArmour Armour { get; set; }
[Inject]
protected IWeapon Weapon { get; set; }
[Inject]
private IAction Jump { get; set; }
[Inject]
private IInstanceProvider InstanceProvider { get; set; }
}
下面是如何执行注入和在注入值后运行构造函数的粗略方法。这是一个功能齐全的程序。
public class InjectAttribute : Attribute
{
}
public class TestClass
{
[Inject]
private SomeDependency sd { get; set; }
public TestClass()
{
Console.WriteLine("ctor");
Console.WriteLine(sd);
}
}
public class SomeDependency
{
}
class Program
{
static void Main(string[] args)
{
object tc = FormatterServices.GetUninitializedObject(typeof(TestClass));
// Get all properties with inject tag
List<PropertyInfo> pi = typeof(TestClass)
.GetProperties(BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Public)
.Where(info => info.GetCustomAttributes(typeof(InjectAttribute), false).Length > 0).ToList();
// We now happen to know there's only one dependency so we take a shortcut just for the sake of this example and just set value to it without inspecting it
pi[0].SetValue(tc, new SomeDependency(), null);
// Find the right constructor and Invoke it.
ConstructorInfo ci = typeof(TestClass).GetConstructors()[0];
ci.Invoke(tc, null);
}
}
我目前正在做一个类似这样的爱好项目 https://github.com/Jokine/ToolProject/tree/Core
传入参数的困难不是问题。问题是你的类做的太多了,应该再分解一些。
依赖注入可以作为类变得太大的早期警告,特别是因为传递所有依赖的痛苦正在增加。
注入容器是一个您最终会后悔的快捷方式。
过度注入不是问题,它通常是其他结构缺陷的症状,最明显的是关注点分离。 这不是一个问题,而是有很多来源,让这个问题变得如此难以解决的是,你将不得不处理所有的问题,有时是在同一时间(想象解开意大利面条)。
这里是一个不完整的注意事项列表
糟糕的域设计(聚合根目录....等)
关注点分离差(服务组合,命令,查询)参见CQRS和事件来源。
或绘图器(要小心,这些东西会给你带来麻烦)
视图模型和其他DTO(永远不要重用它们,并尽量将它们保持在最小值!!!!)
一个方法的参数太多是一个暗示(不一定),你的方法太大/有太多的责任。
此外,在同一方法中使用的参数(可能)具有很高的内聚性——>值得考虑将它们放在一个类中——>只必须传递一个参数。