DI原则下应该注入什么作为Ctor参数？
我试图了解哪些对象应该注入到对象中，哪些对象应该在内部创建。
- 如果我有一些
List（作为数据字段），它保存在运行时收集的信息。看来我应该在 c'tor 中初始化它而不是注入它。
但是通过 COM 端口进行通信的硬件类又如何呢？
我应该让硬件类初始化串行端口还是我注入它？
- 如果需要注入上面提到的SerialPort；最好的方法是什么？
我应该手动创建它：
SerialPort port = new SerialPort(name, baud ...);
HWClass hwClass = container.Reolve<IHWClass>("HWClass", new InjectionConstructor(port));
还是使用 Unity 容器
SerialPort port = conatiner.Resolve<SerialPort>(...);
HWClass hwClass = container.Reolve<IHWClass>("HWClass", new InjectionConstructor(port));
，还是应该在 HWClass C'tor 内初始化它？
阿迪尔
I'm trying to understand which objects should be injected into an object and which should be created internally.
- If i have some
List<int>(as data field) which holds infomation gathered during run time. it seems that i should init it in the c'tor instead of injecting it.
but what about a hardware class which communicates through a COM port.
do i let the HW class init the SerialPort or i inject it ?
- If the above mentioned SerialPort needs to be injected; what is the best way to do it ?
do i create it manually :
SerialPort port = new SerialPort(name, baud ...);
HWClass hwClass = container.Reolve<IHWClass>("HWClass", new InjectionConstructor(port));
or using the Unity container
SerialPort port = conatiner.Resolve<SerialPort>(...);
HWClass hwClass = container.Reolve<IHWClass>("HWClass", new InjectionConstructor(port));
or should i init it inside the HWClass C'tor ?
adiel
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
领域驱动设计区分服务和其他域对象（实体和值对象）。即使您不订阅 DDD，这种区别也非常有用。
服务通常是长期存在的无状态对象，为其消费者执行操作。它们是典型的依赖项，您可以从注入中受益匪浅。
就您而言，SerialPort 和 IHwClass 听起来非常像服务，因为它们代表外部资源，因此我将通过构造函数注入肯定注入它们。
但是，只有注入抽象，您才能真正获得松散耦合的好处。 IHWClass 看起来不错，因为它是一个接口，但 SerialPort 看起来像一个具体的类，因此注入它并不会带来太多好处。从 SerialPort（例如 ISerialPort）中提取接口并注入会更好。
Domain-Driven Design distinguishes between Services and other Domain objects (Entities and Value Objects). Even if you don't otherwise subscribe to DDD, this distinction is very useful.
Services are typically long-lived, stateless objects that perform operations for their consumers. They are the typical dependencies that you can benefit greatly from injecting.
In your case, both SerialPort and IHwClass sounds very much like services because they represent external resources, so I would definitely inject them via Constructor Injection.
However, you only really gain the benefit of loose coupling if you inject an abstraction. The IHWClass looks fine because it's an interface, but the SerialPort looks like a concrete class, so you don't gain much from injecting it. Extracting an interface from SerialPort (say, ISerialPort) and injecting that instead would be better.
我的一般规则是，如果对象可以从类外部更改其状态，或者您希望能够在测试中或在将来的某个时刻动态地提供替代实现，则应该注入它。如果该类仅在内部使用和修改，并且实现仅依赖于包含的类，那么在内部创建依赖关系可能就可以了。要使用您的示例，我将注入
SerialPort，但不注入List。顺便说一句，既然我进行了 TDD（测试驱动开发），我发现我真的不太担心这些决定。您很快就会知道需要注入哪些类，以便解耦您的类以使测试更容易。即使您一开始没有做对，在几次测试后您会发现您的代码自然地朝这个方向发展。
My general rule is that if the object can have it's state changed from outside your class or you want to be able to supply an alternate implementation either in testing or at some point in the future dynamically, you should inject it. If the class is only used and modified internally and the implementation is only dependent on the containing class, then creating the dependency internally is probably ok. To use your example, I would inject
SerialPort, but not theList<int>.As an aside, now that I do TDD (Test Driven Development), I find that I really don't worry too much about these decisions. You pretty quickly reach that point that you know which classes need to be injected in order to decouple your classes to make testing easier. Even if you don't get it right at first, within a few tests you find your code naturally evolving in that direction.