IoC Windows服务体系结构
我传统上是一个SQL人。 我有很多C＃经验，但这些都倾向于工具或定制项目。
我现在的任务是编写一个应用程序，执行以下操作...
所以，这是我第一次进入IoC，并且我正在尽我所能来正确地做事。 我使用Autofac，对这些概念很满意。 我的问题在于理解组合根，何时可以通过容器，我用什么来取代传统的“工厂”概念。 我的应用程序使用L2S模型和通用存储库接口进行构建。 我使用Autofac模块来注册具体类型。 我有一个记录器，并使用一个模块来注册具体类型。 在我的测试控制台应用程序（将由Windows服务主机取代）中，我创建了一个容器并注册了记录器和dal模块等。然后我可以使用构造函数注入来解析我的文件观察类以注入记录器和存储库。 我还注入了一个队列对象（在我的情况下是一个支持内存的队列，但可能是一个数据库队列），新文件被排入队列（生产者）。 在队列的另一端，我需要一个消费者。 所以，根据正在出队的文件的类型，我需要使用不同的加载器类。 我会历史上使用工厂模式来返回适当的具体类。 由于加载器类需要注入一个记录器和适当的存储库，我看不到如何创建适当的加载器类的实例来处理来自队列的项目，而不会给我的工厂类引用IoC容器。 我知道我可以将各种项目处理程序注入到我的消费者类中，但是说我有50个文件类型，或100个，这是不切实际的。
在我明白如何做到这一点之后，我需要做类似的事情来观察新的解析工作（db表中的条目）并处理它们，但我认为它会遵循与上述类似的模式。
任何建议人？ 我距离装饰我的C＃并转到SSIS来加载文件，然后在SSIS中攻击一些讨厌的解析器代码。 请帮助C＃学习者。
我已经意识到，我可以创建一堆加载器类并将它们放入字典中，并将其传递给构造器。 这使我可以通过名称索取装载机。
这听起来像是你试图容器在你的应用程序中构建每个实体 - 谨慎地使用DI，并且只有在你需要可替换的行为的地方，在适当的时候，普通的旧“新”没有任何问题。
另一个建议可能是用一个接口标记你的自定义文件加载器，比如说IFileLoader，通过所有加载的程序集运行并且（使用反射）检测实现的加载器。 然后，将所有装载器组装在一个责任链中，以便如果一个装载器不能处理相关的文件类型，则将责任传递给下一个。 这样，添加新的加载程序将很容易，并且文件监视部分明显与加载部分分离。 COR模式不是必须的，当然可以用简单的循环提供功能。
这是我对你作为新手应该如何开始的看法。
开始写你的课程。 所有对其他类的依赖都在构造函数中进行。
既然你从来没有创建过一个类来获得一个实例，而不是在构建你的对象的时候，它会让你的程序看起来像这样：
static void Main(..) {
var s1 = ...;
var s2 = ...;
var sn = ... SN(s1, s2, ..);
sn.Wait();
}
现在，您可以将所有......替换为容器中的注册。 你根本不使用工厂类; IoC容器是您的工厂。 然后你替换root初始化：
var sn = container.Resolve<SN>();
现在您正在使用IoC。 不要使用字典。
链接地址: http://www.djcxy.com/p/11249.html