3

前段时间我有一个类似的问题，但对整个 IoC/DI 主题以及我想要实现的目标的掌握要少得多，所以又来了....

我正在建立一个图书馆供我们​​公司内部使用。公共 API 中最常用的部分已经对 IoC 友好，但在较低级别的区域中，仍有相当多的新功能在进行，我想摆脱它们（尽管此时更多是出于正式原因而不是实际原因必要性）。

这本身很容易做到，但是当然每次使用库时，都必须重新连接所有组件。由于这看起来几乎总是一样的，我通常只是将这些默认注册包装在 Autofac 模块中并完成它。

（这里的问题 1：这个模块是放在主库程序集中还是应该是一个独立的包，即使 Autofac 可能是库中唯一使用的 IoC 容器？）

现在的问题是，我是公司目前唯一真正了解 IoC 目的或知道 IoC 容器做什么的开发人员，更不用说它是如何使用的了，告诉其他人他们是一个坏主意可以使用 Autofac 包，也可以使用穷人的 DI 手动构建十几个对象的图形。（我认识这些人——他们只会不理会它，自己建造他们需要的东西，因为无论如何我对我所有的小班都很疯狂。）

我想解决这个问题的是添加类似服务定位器的东西，从中提取常用类型的预配置对象（看起来与 Autofac 模块连接的那些相同），可能由轻量级 IoC 容器在内部连接.

我知道服务定位器是一种反模式以及它会产生哪些类型的问题，我永远不会将其用作（我的）对象组合方式，而是作为 IoC/SOLID 受损的“捷径”，是否可行? 我还有什么其他选择？在这种情况下，将 Autofac 模块包含在库中并让“服务定位器”充当它的前端是否有意义？

4

1 回答 1

4

对于框架，与业务线应用程序不同的规则。在我看来，这在应用依赖注入时也是如此。在查看Microsoft 模式和实践企业库的设计时，您会看到这一点. 它完全围绕依赖注入模式设计，但普通用户不会知道这一点。它使用工厂让用户的生活更轻松。在您的情况下，强迫其他开发人员使用依赖注入是不明智的，因为这可能只会惹恼他们，因为您正在做的事情似乎让事情变得更难，他们不会看到它的好处。这可能会让他们对整个 DI 事物产生负面感觉，并且您将失去稍后向他们介绍 DI 的可能性（因为他们已经下定决心不喜欢它）。

这个模块会放在主库程序集中还是应该是一个独立的包

我通常不会将它集成到库本身中，因为从架构的角度来看，您根本不希望您的库依赖于任何 DI 容器。但是，当您查看 Enterprise Library 时，您会发现它严重依赖于 Unity DI 框架。您可以更改 EntLib 以使用不同的容器，但 EntLib 仍然引用 Unity。这允许框架设计者为用户提供方便的工厂方法，并且允许使用框架，而无需在您的应用程序中调用某种“Framework.Bootstrap”方法。

尽你最大的努力设计你的框架，牢记SOLID原则，因为你知道这是最好的做法。它还允许您展示这种在未来设计应用程序的方式（并且可能会让其他人对依赖注入感兴趣）。但作为一名框架设计师，你必须考虑你的用户是谁，并想出一个适合他们的 API。例如，牢记 .NET 的框架设计指南会有所帮助。

查看 Enterprise Library 时，您会看到 root/main 类型有一个工厂。其他一切都在幕后为您解决。我认为这是要走的路。不要用 API 来打扰您的用户，因为他们需要自己连接所有东西，尤其是对于普通/简单的用例。

于 2012-06-25T14:24:32.050 回答