依赖注入＆QUOT;筑巢＆QUOT;在相关方法 [英] Dependency Injection "nesting" in related methods
问题描述
我们正在使用DI和统一不同的相关性工作（通常，数据库和存储库类，DTO到实体映射器等） 现在，我们正在努力，以增加可测试性创建更小的功能，执行任务的尝试彼此无关！，同时也避免了有很多的不同的责任，以避免耦合方法
有一个问题，我有是，应该如何DI被使用时，我们必须依赖于其他内部方法的方法，当嵌套是不平凡的。例如，考虑下面的例子（只是一个概念，没有实际工作code）：
公共ProcessedOrder ProcessOrders（订购inputOrder）
{
的foreach（在inputOrder.OrderLines VAR行）
{
变种someData = LineProcessor（线）;
}
}
公共SomeData LineProcessor（订单行线）
{
/ *做一些东西* /
VAR OtherData = ThingProcessor（空，line.SomeStuff）;
VAR RET =新SomeData（）;
//赋值，更多的东西
返回RET;
}
公共OtherData ThingProcessor（IDep1 someDependency，SomeStuff的东西）
{
someDependency = someDependency？ ServiceLocator.Resolve＆其中; IDep1＆GT;（）;
VAR RET = someDependency.DoThings（东西）;
返回RET;
}
好了，到目前为止，这个例子表明，我们有3个功能，即理论上可以叫上自己。有一个在ThingProcessor注入一些依赖，如果它是null，则它试图解决它。 然而，这是一个莫名其妙简单的例子，但我看到的东西我不喜欢那么多。举例来说，我打电话ThingProcessor与在第一个参数为空值。所以我可以说，好吧，我修改LineProcessor的签名有它注入，让他把它传递到需要它的其他功能。但是，他真的不需要它，它不是它的依赖，但是，他是调用函数。 所以在这里我不知道什么方法是比较正确的，如果我展示，或者我是否应该通过跨层的相关性依赖的人。如果我这样做最后一件事，那么最外面的功能将是一个烂摊子，因为这将有依赖，这将养活大家，是它下面的一个长长的清单。 然而，零办法，我不很喜欢，所以我pretty的确定什么是错的地方，而且有可能是一个更好的方式来设计这个。 什么是最好的方法？？？请记住，所有函数都必须独立使用（叫上自己的），因此，例如我可以打电话只是ThingProcessor在某些时候，或者在另一只LineProcessor。
更新：
公共CommonPurposeFunctions（IDep1 DEP1，IDep2 dep2 ....）
{
this.Dep1 = DEP1;
this.Dep2 = dep2;
[...]
}
公共ProcessedOrder ProcessOrders（订购inputOrder）
{
的foreach（在inputOrder.OrderLines VAR行）
{
变种someData = LineProcessor（线）;
}
}
公共SomeData LineProcessor（订单行线）
{
/ *做一些东西* /
VAR OtherData = ThingProcessor（line.SomeStuff）;
VAR RET =新SomeData（）;
变种morethings = this.Dep2.DoMoreThings（）;
//赋值，更多的东西
返回RET;
}
公共OtherData ThingProcessor（SomeStuff的东西）
{
VAR RET = this.Dep1.DoThings（东西）;
返回RET;
}
我们使用的方法是构造器注入，那么我们就存储在私有成员字段的依赖。容器直径达的依赖;因此类和构造函数参数的数量并不重要。
这适用于服务。如果在调用的依赖性有有意义的状态，你必须通过他们给每个呼叫。但是，在这种情况下，我会质疑，如果这些方法确实需要在自己的类的公共方法。
您想结束了，消除了服务定位器，并真正实现了设计的其注入的相关性。
We're using DI and Unity to work with different dependencies (generally, database and repository classes, dto to entity mappers, etc) Right now we're trying to create smaller functions that perform tasks that try to be independend from each other, in order to increase testability and also to avoid methods that have lots of different responsibilities, to avoid coupling
One question that I have is, how should DI be used when we have methods that rely on other inner methods, when the nesting is not trivial. For example, consider the following example (just a concept, not real working code):
public ProcessedOrder ProcessOrders(Order inputOrder)
{
foreach (var line in inputOrder.OrderLines)
{
var someData = LineProcessor(line);
}
}
public SomeData LineProcessor(OrderLine line)
{
/* do some stuff*/
var OtherData = ThingProcessor(null,line.SomeStuff);
var ret = new SomeData();
// assign values, more stuff
return ret;
}
public OtherData ThingProcessor(IDep1 someDependency, SomeStuff stuff)
{
someDependency = someDependency ?? ServiceLocator.Resolve<IDep1>();
var ret = someDependency.DoThings(stuff);
return ret;
}
Ok, so far the example shows that we have 3 functions, that could theoretically be called on their own. there's some injected dependency in the ThingProcessor, and if it's null then it tries to resolve it. However, this is a somehow simple example, but I see something I don't like so much. For instance, I'm calling ThingProcessor with a null value in the first param. So I can say, ok, I modify the signature of LineProcessor to have it injected, so that he pass it in to the other function that needs it. However, he really doesn't need it, it's not its dependency but the function that he's calling. So here I don't know what approach is the more correct one, if the one that i'm showing, or if I should pass the correlated dependencies across layers. If I do this last thing, then the outermost function will be a mess, because it'll have a long list of dependencies that it will feed to everyone that's below it. However, the "null approach" I don't like very much, so I'm pretty sure that something's wrong somewhere, and there's probably a better way to design this. What's the best approach??? Remember, all functions must be used independently (called on their own), so for example I may call just ThingProcessor at some point, or at another one only LineProcessor.
UPDATE :
public CommonPurposeFunctions(IDep1 dep1, IDep2 dep2 ....)
{
this.Dep1 = dep1;
this.Dep2 = dep2;
[...]
}
public ProcessedOrder ProcessOrders(Order inputOrder)
{
foreach (var line in inputOrder.OrderLines)
{
var someData = LineProcessor(line);
}
}
public SomeData LineProcessor(OrderLine line)
{
/* do some stuff*/
var OtherData = ThingProcessor(line.SomeStuff);
var ret = new SomeData();
var morethings = this.Dep2.DoMoreThings();
// assign values, more stuff
return ret;
}
public OtherData ThingProcessor(SomeStuff stuff)
{
var ret = this.Dep1.DoThings(stuff);
return ret;
}
The approach we use is constructor injection, then we store the dependency in a private member field. The container wires up the dependencies; so the number of classes and constructor parameters doesn't really matter.
This works for services. If the dependencies across calls have meaningful state, you will have to pass them in to each call. But, in that case, I'd question if the methods really need to be public methods in their own classes.
You want to end up with a design that eliminates the service locator and truly injects the dependencies.
这篇关于依赖注入＆QUOT;筑巢＆QUOT;在相关方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
