相关疑难解决方法(0)

我正在思考一个C#库的设计,它将有几个不同的高级函数.当然,这些高级功能将尽可能使用SOLID类设计原则来实现.因此,可能存在供消费者定期直接使用的类,以及作为那些更常见的"最终用户"类的依赖性的"支持类".

问题是,设计库的最佳方法是:

• DI不可知 - 虽然为一个或两个常见的DI库(StructureMap,Ninject等)添加基本的"支持"似乎是合理的,但我希望消费者能够将该库与任何DI框架一起使用.
• 非DI可用 - 如果库的使用者没有使用DI,那么库应该仍然尽可能容易使用,减少了用户为创建所有这些"不重要"的依赖关系而必须完成的工作量.他们想要使用的"真实"类.

我目前的想法是为常见的DI库提供一些"DI注册模块"(例如,一个StructureMap注册表,一个Ninject模块),以及一个非DI的集合或工厂类,并包含与这几个工厂的耦合.

思考？

假设我有一些类Foo,它有两个依赖:an ISerializer<T>和an IFileAccessHandler.

现在这个类还有其他依赖项,功能依赖项.我不希望任何人在无效状态下实例化这个类,所以我还需要在构造函数中传递一个域对象.

但是,当我实际创建类Foo的那一刻,当我也知道要传递哪个域对象时,如何处理IoC？

我使域对象成为我由Factory设置的属性.因此,Factory会调用Service Locator来获取一个正确实例化的"Foo"类及其依赖项,并进一步使用正确的域对象填充它并返回它.

但这是最好的方式吗？我宁愿让我的构造函数的域对象部分让它变得明确,你实际上需要使用"Foo".

有任何想法吗？我在这里错过了什么吗？