Castle Windsor（或任何 IoC 框架）和内部依赖项

Question

我在使用内部类型的依赖注入时遇到了一些麻烦。尽管我已经使用 Castle Windsor 几年了，但我从来没有真正考虑过太多的可见性，所以一切通常最终都是公开的（部分是为了让 Windsor 开心，部分是为了便于在单元测试中进行模拟） .但是我现在需要设计一个 API。

我很欣赏下面的示例不是很好，但它旨在说明公开具有不应公开访问的依赖项的类型的场景。

假设我的 API 层公开了一个 GetCustomer() 方法。这将返回一个 Customer 类，该类公开一个 SendEmail() 方法，该方法利用 MailService 类来实现电子邮件发送。

我想将 MailService 注入客户，但我不希望 API 的使用者可以访问 MailService。我相信它不能是内部的，因为您不能将内部类型传递给公共构造函数。因此，将 Customer ctr 设置为内部是有意义的（因为只有 BLL 应该创建它们），但 Windsor 抱怨说，因为注册的类型必须有一个公共 ctr。

我觉得我在这一切中缺少一些基本的东西。我将如何设计这样的东西？我想一种解决方案是接口，但是当（通常）只有一个实现时，为每种内部类型创建一个接口不知何故感觉不对。

Answer 1

我相信它不可能是内部的，因为您不能将内部类型传递给公共构造函数。

如果公共构造函数依赖于内部类型，C# 将不会编译您的类，这是显而易见的。但实际上你可以将内部实现传递给公共构造函数，只要构造函数所依赖的接口也是公共的。

因此，将 Customer ctr 设置为内部是有意义的

这不是将构造函数设为内部的好理由，因为这样可以正常工作，但如果您正在构建一个可重用的库，则将构造函数设为内部是非常有效的，因为一旦您发布了库，更改公共构造函数就是一个突破性的变化。因此，将其设为内部是让图书馆在未来发生变化和发展的好方法。

但是 Windsor 抱怨，因为注册类型必须有一个公共 ctr。

大多数 DI 库允许覆盖默认构造函数解析行为，如 does Castle Windsor。

因为您正在创建一个可重用的库，我强烈建议您阅读Mark Seemann's DI Friendly Library 文章。