xml配置还是通过代码配置?
我个人喜欢从 C# 代码配置 StructureMap 的选项。据我了解,DI 的优点之一是我们可以轻松地交换新的具体实例。但是,如果配置是在代码中定义的,则具体实例将硬编码在 dll 中。
因此,实际上,它与对依赖项进行硬编码一样好,对吧?我知道,在测试过程中它会让生活变得更轻松...
我的观点是,使用 xml 配置不是更好吗?你想插入一个新的具体实例吗?只需让安装程序用新文件覆盖 Structuremap.config 文件即可。
那么,配置 StructureMap 的首选方式是什么?
额外:我暂时被迫使用 C# 配置,因为我不知道如何将连接字符串传递给实例。我可以在配置文件中写入连接字符串,但我想重用 app.config 中定义的连接字符串。
I personally like the option to configure StructureMap from C# code. From what I understand, one of the advantages of DI, is that we can easily swap in a new concrete instance. But, if the configuration is defined in code, then the concrete instances are hardcoded in the dll.
So, practically, its as good as having hard coded the dependencies, right? I know, during testing it makes life easier...
My point is, wouldnt it be better to use xml configuration instead? you want to plugin a new concrete instance? simply have your installer overwrite the structuremap.config file with the new one.
So, what is the preferred way to configure StructureMap?
Extra: Am forced to use C# configuration for the time being because I dont know how to pass the connection string to instance. I can write the connectionstring in the config file, but i would like to reuse the connectionstring defined in app.config.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
无论您使用哪个特定的 DI 容器,您都应该始终将应用程序对象图的解析推迟到 最后一个负责任的时刻。这称为应用程序的组合根。
您可以编写大部分应用程序,而无需引用 DI 容器 。这也意味着您可以推迟在代码配置还是配置中做出决定,直到您需要为止。
您根本不需要容器进行单元测试,但可能需要用于集成测试。但是,在集成测试中,您可能需要与最终应用程序不同的容器配置。
总而言之,在代码中配置容器是当今的首选方法,因为它更健壮,并且您可以应用基于约定的配置机制。
XML 配置往往更脆弱且过于冗长。在大多数情况下,它只会减慢您的速度,因为您没有重构或编译器支持。
但是,当您需要能够交换依赖项而不重新编译应用程序时,XML 配置仍然有效。大多数 DI 容器将允许您混合使用这些方法,以便您可以在代码中拥有大部分配置,但出于可扩展性的原因,在 XML 中定义一些选定的依赖项。
No matter which particular DI Container you use, you should always defer the resolution of the application's object graph to the last responsible moment. This is called the application's Composition Root.
You can write the bulk of your application without ever referencing the DI Container. This also means that you can defer the decision between configuration in code or config until you need it.
You shouldn't need the container at all for unit testing, but may need it for integration testing. However, in integration tests, you will likely need a different configuration for the container than in the final application.
All in all, configuring the container in code is the preferred approach these days because it's more robust and you can apply convention-based configuration mechanics.
XML configuration tends to be more brittle and too verbose. In most cases, it simply slows you down because you get no refactoring or compiler support.
However, XML configuration is still valid when you need to be able to swap dependencies without recompiling the application. Most DI Containers will let you mix those approaches so that you can have most of your configuration in code, but a few selected dependencies defined in XML for extensibility reasons.
要回答您的问题,您可以在 StructureMap 中鱼与熊掌兼得。您可以从代码配置容器,并从应用程序配置中推送您需要的额外配置。这就是 EqualToAppSetting 的用途。
创建一个设置类
接下来告诉 StructureMap 使用您的应用程序设置来配置它。
最后,这是我的应用程序配置中的应用程序设置:
To answer your question you can have your cake and eat it too in StructureMap. You can configure your container from code and push in that extra bit of config you need from the application configuration. That is what EqualToAppSetting is for.
Create a settings class
Next tell StructureMap to configure it using your application settings.
Finally here is what the application settings look like in my application config: