配置设置和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.
例如
如果控制器需要实例化业务层类，需要实例化存储库类，需要连接类，需要设置值，则无需在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类，存储库类和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允许您将许多构造函数参数包装到Single Aggregate服务接口中，以便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屋！
