配置设置和 IoC [英] configuration settings and IoC
问题描述
我使用 IoC (DI) 方法并且通常有参数，这些参数是由最低层(DB 层等)从配置设置(即连接字符串、静态值等)中读取的.最好的方法是什么?
I use IoC (DI) approach and usually have parameters, which are being read from configuration settings (i.e. connection strings, static values etc) by the lowest layer (DB layer etc). What is the best way to do it?
直接在这个最低层读取，即:
Read directly in this the lowest layer, i.e.:
string sendGridApiKey = ConfigurationManager.AppSettings["SendGridApiKey"];
它可以工作，但还需要将此密钥添加到单元测试项目的配置文件中.另外，程序集依赖于配置文件
It works, but need to add also this key to config file of unit test project. Also, assembly depends on configuration file
- 在最高层(即 Web 应用程序)读取它并从所有层作为参数抛出?它会起作用，但是所有中间层都会获得未使用的参数(因此，它们将取决于未使用的事物).
当最低层的不同实现可能需要不同的参数时，也存在一个问题.IE.SendMail1 可以需要 SMTP/登录名/密码，而 SendMail2 可以只需要 ApiKey，但 SendMail1 和 SendMail2 应该实现相同的接口.因此，使用方法#2 会造成困难
Also there is a problem when different implementations of the the lowest layers can require different parameters. I.e. SendMail1 can require SMTP/login/password, but SendMail2 can require only ApiKey, but SendMail1 and SendMail2 should implement the same interface. So, it creates difficulties to use approach #2
推荐答案
选项 1 开始时是一个更简单的解决方案，但很快就变得难以测试，需要参考，打破了围绕从最高层到最低层流动值的模式等
option 1 starts out as a simpler solution, but pretty soon ends up being difficult for testing, needing references, breaking a pattern around flowing values from highest to lowest layers etc.
推荐的模式是#2，最高层将所有依赖项及其值向下层发送.
The recommended pattern is #2, where the highest layer sends down all dependencies and their values to the lower layers.
即使您必须将其传递到所有层，您的 DI 引擎也应该在自动链接解析方面为您提供帮助.
Even though you have to pass it down across all layers, your DI engine should help you here in terms of automatic chained resolution.
例如
如果你的控制器需要实例化一个业务层类，需要实例化一个Repository类，需要一个Connection类，需要设置值，就不需要手动在3处做.
If your controller needs to instantiate a Business Layer class, which needs to instantiate a Repository class, which needs a Connection class, which needs the setting value, you don't need to manually do it at 3 places.
您可以在 DI 引擎中分别定义 BL 类、Repository 类和 Connection 类的注册，它会为您实例化控制器.
You can define registrations of BL class, Repository class and Connection class separately in the DI engine, and it'll take care of instantiating a controller for you.
它可能看起来很乏味，但从长远来看通常会有很大的好处.(在明确的合同定义、单元测试、无反模式、孤立的关注点等方面)
It may look tedious, but normally has great benefits in the long run. (in terms of clear contract definition, unit testing, no anti-pattern, isolated concerns etc.)
如果您真的担心超过 3 个位置，则在工厂和聚合服务方面有多种选择.每个都有其优点/缺点，并取决于您使用的 DI 引擎.如果选项 2 绝对不能接受，请告诉我们.
And if you are really worried about passing it 3 places, there are various options in terms of Factories and Aggregate services. Each have their pros/cons and depend on the DI engine you are using. Let us know if option 2, is absolutely unacceptable.
例如Autofac 允许您将大量构造函数参数包装到单个聚合服务接口中，以便 Autofac 可以为您注入.
e.g. Autofac allows you to wrap a lot of constructor parameters into a Single Aggregate service interface, so that Autofac can inject that for you.
这篇关于配置设置和 IoC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
