我有一个连接到com端口的类.我允许用户选择com端口号.现在,我将该com port参数作为构造函数参数.原因是如果没有那些信息,类就无法运行,而且它的实现是特定的(这个类的模拟版本不需要com端口).
另一种方法是使用“开始”方法接收com端口,或者具有设置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(或您的具体实现),并且您仍然可以灵活地为接口编程.
缺点是它增加了另一层间接.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
