使用 container.RegisterAll<TService>() 时解析组件
Resolving components when using container.RegisterAll<TService>()
我在 类 中尝试注入依赖项时遇到问题。当我被困在这里时,我只是想了解更多关于简单注入和 DI 的知识。
所以这是我的主要方法:
static void Main(string[] args)
{
var container = new Container();
// Registrations here
container.RegisterAll<ISimpleLogger>(typeof(DebugLogger), typeof(ConsoleLogger));
container.Verify();
Product p = new Product();
p.TestLog();
Console.ReadKey();
}
这是我的另一个 类:
public interface ISimpleLogger
{
void Log(string content);
}
public class DebugLogger : ISimpleLogger
{
public void Log(string content)
{
Debug.WriteLine(content);
}
}
public class ConsoleLogger : ISimpleLogger
{
public void Log(string content)
{
Console.WriteLine(content);
}
}
public class Product
{
public string Name { get; private set; }
public decimal Price { get; private set; }
public Product(string name, decimal price)
{
Name = name;
Price = price;
}
private readonly ISimpleLogger[] loggers;
public Product(params ISimpleLogger[] _loggers)
{
this.loggers = _loggers;
}
public void TestLog()
{
foreach (var item in loggers)
{
item.Log("testing...");
}
}
public static List<Product> GetSampleProducts()
{
return new List<Product>
{
new Product { Name="West Side Story", Price = 9.99m },
new Product { Name="Assassins", Price=14.99m },
new Product { Name="Frogs", Price=13.99m },
new Product { Name="Sweeney Todd", Price=10.99m}
};
}
}
1) 我在任何地方都看不到输出 "Testing..."。
2) 调试我的应用程序,当调用 Product 构造函数时,它不会注入依赖项,因此我的数组保持 0 项。
应该是什么?设置容器时配置错误?
问题很简单,您似乎已经正确配置了 container
但您没有要求它创建您的 Product
对象,因此能够注入依赖项。
不要自己 new
启动 Product
,请 container
为您完成...
static void Main(string[] args)
{
var container = new Container();
// Registrations here
container.RegisterAll<ISimpleLogger>(typeof(DebugLogger), typeof(ConsoleLogger));
container.Verify();
Product p = container.GetInstance<Product>();
p.TestLog();
Console.ReadKey();
}
我认为您还需要更改 Product
的构造函数以采用 IEnumerable<>
private readonly IEnumerable<ISimpleLogger> loggers;
public Product(IEnumerable<ISimpleLogger> loggers)
{
this.loggers = loggers;
}
通过依赖注入,我们构建了组件的对象图。组件是我们应用程序中包含应用程序行为的 classes。这种对象图通常由长期服务组成。这些服务本身不应该包含任何状态。状态(或运行时数据)应该使用方法调用通过这个对象图推送。任何时候违反这个基本原则,都是自找麻烦。
您的 Product
class 是一个实体。这是一个包含状态的短暂对象。防止 DI 库构建包含状态的对象。这会导致歧义和可维护性问题。
这已经发生在你的案例中,因为你想创建一个 Product
class,你希望它是不可变的。所以这意味着它需要通过构造函数进行初始化。另一方面,您还希望将其依赖项注入构造函数,为此您有第二个构造函数。但是你只能调用一个构造函数;所以你的 Product
要么是没有依赖关系的有效产品,要么是有依赖关系的无效产品。
虽然您可以通过将两个构造函数合并在一起来解决这个问题,但这会导致同样多的麻烦,因为现在您将不得不要求 DI 容器为您构建此 Product,但 DI 容器知道与它必须提供的原语无关(在您的情况下是名称和价格)。
在我的项目中,我通常使用 anemic domain model. This means that my entities don't have any logic in them. Instead I use commands and queries 作为领域模型动词的定义。其他人不喜欢这样,喜欢将域逻辑作为域对象的一部分(尽管这两种模型并不相互排斥,但一些开发人员结合使用这些概念)。由于域逻辑有时需要与服务一起工作,这些实体显然需要提供这些依赖项。但是,这并不意味着您必须在此处使用构造函数注入。
这种情况下方法注入就方便多了。这意味着您的 Product
class 将如下所示:
public class Product
{
public string Name { get; private set; }
public decimal Price { get; private set; }
public Product(string name, decimal price) {
Name = name;
Price = price;
}
public void TestLog(ISimpleLogger[] loggers) {
foreach (var item in loggers)
{
item.Log("testing...");
}
}
}
所以我们不是通过构造函数传递依赖关系,而是通过实际需要它的方法传递它。方法注入效果更好,因为:
- 你的构造函数冲突消失了。您现在可以使用构造函数创建一个有效的实例,并在需要时提供所需的服务。
- 它会阻止你的构造函数变得有很多依赖项。这将会发生,因为虽然实体上的大多数方法只需要一两个不同的服务,但实体上的所有方法可能需要十几个或更多的依赖项。这变得非常丑陋非常快。您经常会发现域对象上的方法之间没有太多的内聚性,这就是为什么我将此逻辑移到命令处理程序中的原因(但那是另一回事)。
当然,注入这些依赖项的责任现在转移到了调用此域方法的人(在您的情况下为 TestLog
方法)。但这通常不是问题,因为这个消费者将是一个普通的应用程序组件,您可以在其中再次应用构造函数注入。这是一个例子:
public class LogProductCommandHandler : ICommandHandler<LogProduct>
{
private readonly IRepository<Product> productRespository;
private readonly ISimpleLogger[] loggers;
public LogProductCommandHandler(IRepository<Product> productRespository,
ISimpleLogger[] loggers) {
this.productRespository = productRespository;
this.loggers = loggers;
}
public void Handle(LogProduct command) {
Product product = this.productRepository.GetById(command.ProductId);
product.TestLog(this.loggers);
}
}
这个LogProductCommandHandler
可以通过容器来解决。请注意,所有运行时数据 'flows' 通过此处的对象图。我们有这个包含运行时数据的 LogProduct
消息(命令)。它被传递给 Handle
方法。此消息包含一个 ProductId
值,它被传递到存储库的 GetById
方法,该方法将 return Product
(再次运行时数据)。
还有一点。防止将事物列表注入消费者。注入 T[]
数组、IEnumerable<T>
或 List<T>
通常意味着您正在泄漏实现细节。消费者不必知道或担心可能有多种实现的事实 - 在您的情况下 - 一个记录器。注入集合会使消费者复杂化,因为它必须迭代集合。不仅如此,依赖于该集合的每个消费者都需要迭代该集合。这不仅不必要地使所有这些消费者的代码复杂化,还会使您的代码更难更改。有时您会想要更改这些记录器的处理方式。也许您想继续记录到下一个记录器,即使第一个记录器抛出异常。我确定您知道如何编写此类程序;这不是一个很难解决的问题。但它会导致您对代码库进行彻底的更改以实现这一点。
相反,请使用 Composite design pattern。使用复合模式,您可以将一些抽象元素的集合隐藏在实现相同抽象的组件后面。 ISimpleLogger
的复合实现可能如下所示:
public sealed SimpleLoggerComposite : ISimpleLogger
{
private readonly IEnumerable<ISimpleLogger> loggers;
public SimpleLoggerComposite(IEnumerable<ISimpleLogger> loggers) {
this.loggers = loggers;
}
public void Log(string message) {
foreach (var logger in this.loggers) {
logger.Log(message);
}
}
}
这里我们将 foreach
循环移动到 SimpleLoggerComposite
。现在我们可以注册 SimpleLoggerComposite
如下:
// Simple Injector v3.x
container.RegisterSingleton<ISimpleLogger, SimpleLoggerComposite>();
container.RegisterCollection<ISimpleLogger>(
new[] { typeof(DebugLogger), typeof(ConsoleLogger) });
// Simple Injector v2.x
container.RegisterSingle<ISimpleLogger, SimpleLoggerComposite>();
container.RegisterAll<ISimpleLogger>(
new[] { typeof(DebugLogger), typeof(ConsoleLogger) });
现在应用程序的其余部分可以简单地依赖于 ISimpleLogger
而不是 ISimpleLogger[]
。例如:
public class Product
{
...
public void TestLog(ISimpleLogger logger) {
logger.Log("testing...");
}
}
现在您 TestLog
方法中的代码变得非常无聊。但这显然是一件好事。软件开发的诀窍是制作看起来非常简单的软件:-)
我在 类 中尝试注入依赖项时遇到问题。当我被困在这里时,我只是想了解更多关于简单注入和 DI 的知识。
所以这是我的主要方法:
static void Main(string[] args)
{
var container = new Container();
// Registrations here
container.RegisterAll<ISimpleLogger>(typeof(DebugLogger), typeof(ConsoleLogger));
container.Verify();
Product p = new Product();
p.TestLog();
Console.ReadKey();
}
这是我的另一个 类:
public interface ISimpleLogger
{
void Log(string content);
}
public class DebugLogger : ISimpleLogger
{
public void Log(string content)
{
Debug.WriteLine(content);
}
}
public class ConsoleLogger : ISimpleLogger
{
public void Log(string content)
{
Console.WriteLine(content);
}
}
public class Product
{
public string Name { get; private set; }
public decimal Price { get; private set; }
public Product(string name, decimal price)
{
Name = name;
Price = price;
}
private readonly ISimpleLogger[] loggers;
public Product(params ISimpleLogger[] _loggers)
{
this.loggers = _loggers;
}
public void TestLog()
{
foreach (var item in loggers)
{
item.Log("testing...");
}
}
public static List<Product> GetSampleProducts()
{
return new List<Product>
{
new Product { Name="West Side Story", Price = 9.99m },
new Product { Name="Assassins", Price=14.99m },
new Product { Name="Frogs", Price=13.99m },
new Product { Name="Sweeney Todd", Price=10.99m}
};
}
}
1) 我在任何地方都看不到输出 "Testing..."。
2) 调试我的应用程序,当调用 Product 构造函数时,它不会注入依赖项,因此我的数组保持 0 项。
应该是什么?设置容器时配置错误?
问题很简单,您似乎已经正确配置了 container
但您没有要求它创建您的 Product
对象,因此能够注入依赖项。
不要自己 new
启动 Product
,请 container
为您完成...
static void Main(string[] args)
{
var container = new Container();
// Registrations here
container.RegisterAll<ISimpleLogger>(typeof(DebugLogger), typeof(ConsoleLogger));
container.Verify();
Product p = container.GetInstance<Product>();
p.TestLog();
Console.ReadKey();
}
我认为您还需要更改 Product
的构造函数以采用 IEnumerable<>
private readonly IEnumerable<ISimpleLogger> loggers;
public Product(IEnumerable<ISimpleLogger> loggers)
{
this.loggers = loggers;
}
通过依赖注入,我们构建了组件的对象图。组件是我们应用程序中包含应用程序行为的 classes。这种对象图通常由长期服务组成。这些服务本身不应该包含任何状态。状态(或运行时数据)应该使用方法调用通过这个对象图推送。任何时候违反这个基本原则,都是自找麻烦。
您的 Product
class 是一个实体。这是一个包含状态的短暂对象。防止 DI 库构建包含状态的对象。这会导致歧义和可维护性问题。
这已经发生在你的案例中,因为你想创建一个 Product
class,你希望它是不可变的。所以这意味着它需要通过构造函数进行初始化。另一方面,您还希望将其依赖项注入构造函数,为此您有第二个构造函数。但是你只能调用一个构造函数;所以你的 Product
要么是没有依赖关系的有效产品,要么是有依赖关系的无效产品。
虽然您可以通过将两个构造函数合并在一起来解决这个问题,但这会导致同样多的麻烦,因为现在您将不得不要求 DI 容器为您构建此 Product,但 DI 容器知道与它必须提供的原语无关(在您的情况下是名称和价格)。
在我的项目中,我通常使用 anemic domain model. This means that my entities don't have any logic in them. Instead I use commands and queries 作为领域模型动词的定义。其他人不喜欢这样,喜欢将域逻辑作为域对象的一部分(尽管这两种模型并不相互排斥,但一些开发人员结合使用这些概念)。由于域逻辑有时需要与服务一起工作,这些实体显然需要提供这些依赖项。但是,这并不意味着您必须在此处使用构造函数注入。
这种情况下方法注入就方便多了。这意味着您的 Product
class 将如下所示:
public class Product
{
public string Name { get; private set; }
public decimal Price { get; private set; }
public Product(string name, decimal price) {
Name = name;
Price = price;
}
public void TestLog(ISimpleLogger[] loggers) {
foreach (var item in loggers)
{
item.Log("testing...");
}
}
}
所以我们不是通过构造函数传递依赖关系,而是通过实际需要它的方法传递它。方法注入效果更好,因为:
- 你的构造函数冲突消失了。您现在可以使用构造函数创建一个有效的实例,并在需要时提供所需的服务。
- 它会阻止你的构造函数变得有很多依赖项。这将会发生,因为虽然实体上的大多数方法只需要一两个不同的服务,但实体上的所有方法可能需要十几个或更多的依赖项。这变得非常丑陋非常快。您经常会发现域对象上的方法之间没有太多的内聚性,这就是为什么我将此逻辑移到命令处理程序中的原因(但那是另一回事)。
当然,注入这些依赖项的责任现在转移到了调用此域方法的人(在您的情况下为 TestLog
方法)。但这通常不是问题,因为这个消费者将是一个普通的应用程序组件,您可以在其中再次应用构造函数注入。这是一个例子:
public class LogProductCommandHandler : ICommandHandler<LogProduct>
{
private readonly IRepository<Product> productRespository;
private readonly ISimpleLogger[] loggers;
public LogProductCommandHandler(IRepository<Product> productRespository,
ISimpleLogger[] loggers) {
this.productRespository = productRespository;
this.loggers = loggers;
}
public void Handle(LogProduct command) {
Product product = this.productRepository.GetById(command.ProductId);
product.TestLog(this.loggers);
}
}
这个LogProductCommandHandler
可以通过容器来解决。请注意,所有运行时数据 'flows' 通过此处的对象图。我们有这个包含运行时数据的 LogProduct
消息(命令)。它被传递给 Handle
方法。此消息包含一个 ProductId
值,它被传递到存储库的 GetById
方法,该方法将 return Product
(再次运行时数据)。
还有一点。防止将事物列表注入消费者。注入 T[]
数组、IEnumerable<T>
或 List<T>
通常意味着您正在泄漏实现细节。消费者不必知道或担心可能有多种实现的事实 - 在您的情况下 - 一个记录器。注入集合会使消费者复杂化,因为它必须迭代集合。不仅如此,依赖于该集合的每个消费者都需要迭代该集合。这不仅不必要地使所有这些消费者的代码复杂化,还会使您的代码更难更改。有时您会想要更改这些记录器的处理方式。也许您想继续记录到下一个记录器,即使第一个记录器抛出异常。我确定您知道如何编写此类程序;这不是一个很难解决的问题。但它会导致您对代码库进行彻底的更改以实现这一点。
相反,请使用 Composite design pattern。使用复合模式,您可以将一些抽象元素的集合隐藏在实现相同抽象的组件后面。 ISimpleLogger
的复合实现可能如下所示:
public sealed SimpleLoggerComposite : ISimpleLogger
{
private readonly IEnumerable<ISimpleLogger> loggers;
public SimpleLoggerComposite(IEnumerable<ISimpleLogger> loggers) {
this.loggers = loggers;
}
public void Log(string message) {
foreach (var logger in this.loggers) {
logger.Log(message);
}
}
}
这里我们将 foreach
循环移动到 SimpleLoggerComposite
。现在我们可以注册 SimpleLoggerComposite
如下:
// Simple Injector v3.x
container.RegisterSingleton<ISimpleLogger, SimpleLoggerComposite>();
container.RegisterCollection<ISimpleLogger>(
new[] { typeof(DebugLogger), typeof(ConsoleLogger) });
// Simple Injector v2.x
container.RegisterSingle<ISimpleLogger, SimpleLoggerComposite>();
container.RegisterAll<ISimpleLogger>(
new[] { typeof(DebugLogger), typeof(ConsoleLogger) });
现在应用程序的其余部分可以简单地依赖于 ISimpleLogger
而不是 ISimpleLogger[]
。例如:
public class Product
{
...
public void TestLog(ISimpleLogger logger) {
logger.Log("testing...");
}
}
现在您 TestLog
方法中的代码变得非常无聊。但这显然是一件好事。软件开发的诀窍是制作看起来非常简单的软件:-)