我已经使用了大量的依赖注入，但我想获得有关如何在运行时处理来自用户的信息的输入。
我有一个连接到 com 端口的类。我允许用户选择 com 端口号。现在，我将该 com 端口参数作为构造函数参数。原因是如果没有这些信息，该类就无法运行，并且它是特定于实现的（该类的模拟版本不需要 com 端口）。
另一种方法是使用一个接受 com 端口的“Start”方法，或者使用一个设置 com 端口的属性。这使得它与 IoC 容器非常兼容，但从类的角度来看它不一定有意义。
看起来逻辑路线与依赖注入设计相冲突，但这是因为我的 UI 正在获取特定类型的类的信息。
其他替代方案包括使用 IoC 容器，它允许我传递额外的构造函数参数，或者仅在顶层构造我需要的类，而不使用依赖注入。
对于此类问题是否有普遍接受的标准模式？
您可以选择两条路线，具体取决于您的需要。
1. 将 UI 直接连接到具体类
这是最简单的选择，但很多时候是完全可以接受的。虽然您可能有一个包含大量接口并使用 DI 的域模型，但 UI 构成了对象图的组合根，您可以简单地在此处连接您的具体类，包括所需的端口号参数。
优点是这种方法简单且易于理解和实施。
缺点是灵活性较差。您将无法任意将一种实现替换为另一种实现（但话又说回来，您可能不需要这种灵活性）。
即使 UI 锁定到具体实现，这并不意味着领域模型本身不能在以下环境中重用：其他应用.
2.添加抽象工厂
另一种选择是添加另一层间接层。它可以使用抽象工厂来创建实例，而不是让 UI 直接创建类。
工厂的Create方法可以将端口号作为输入，因此这种抽象最适合 UI 子层。
public abstract class MyFactory
{
public abstract IMyInterface Create(int portNumber);
}
然后，您可以让您的 DI 容器连接该工厂的实现，该工厂使用端口号并将其作为构造函数参数传递给您的实际实现。其他工厂实现可能会简单地忽略该参数。
这种方法的优点是您不会污染您的 API（或您的具体实现），并且您仍然拥有接口编程所提供的灵活性。
缺点是它增加了另一层间接性。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
