StaticFactory是吗？在 codecampserver 中有一个众所周知的模式吗？
CodeCampServer 源代码包含通用 StaticFactory< /a>.
我猜测这是框架如何与依赖注入良好配合的机制的关键部分。
其子类使用 DefaultUnconfiguredState 为自己提供对默认未配置状态的静态访问，依赖项解析机制可以用工作内容替换该状态。
我找不到这方面的任何文档...
...或者其他人可以对这是什么以及我是否明智地采用这种模式提供一个很好的评论（如果是一个...）？
更新
自从 Jeffrey Palermo 回答了这个问题以来，我看到在 MVC2 in Action 的（正在进行中的）手稿中，使用用于定位存储库的工厂讨论和说明了这种模式/风格为了使域层不了解持久性问题。 （请参阅第 23 章）。
默认情况下，使用此工厂会引发异常：
“如何创建的知识 存储库不驻留在 工厂。这家工厂仅仅 代表有能力返回 存储库”
可以使用几种机制之一来初始化存储库接口的具体实现。在本书的示例中，为了简单起见，他们选择不使用 IOC 容器，并在某些启动逻辑中显式提供它。
“重要的是，两者都不是 核心项目和 UI 项目 应参考基础设施 纯粹的项目或库 本质上是基础设施。我们有 使 NHibernate 完全关闭 边，以便其余的 应用程序不关心数据如何 正在访问”
注意的是，工厂不再是静态的（至少就面向外部的接口而言）。
更新 2
Mr Palermo 在博客中详细介绍了这种特殊风格的抽象工厂（请参阅OrderShipperFactory 的实现）
我也可以只考虑“手动依赖”注入'（Uncle Bob）
更新 3 - 2016 年 3 月
有 这里的另一个示例，尽管 Jeffrey 明确表示这是演示代码，并且评论表明这将是在 Mark Seeman 所说的 Composition Root 中进行配置（即在应用程序启动时-up)
我在 Jeffrey 的文章“洋葱架构中发现了这一点：第 4 部分 - 四年后”
CodeCampServer source code contains a generic StaticFactory.
I'm surmising that this is a key piece of the mechanism for how the framework plays well with Dependency Injection.
Subclasses of which use it's DefaultUnconfiguredState to provide static access to, well, a Default Unconfigured State for themselves which the dependency resolution mechanism can replace with working stuff.
I've not been able to find any documentation for this...
Is there a good explanation in the book? (I'm awaiting delivery from Amazon...)
...or can anyone else provide a good commentary on what this is and whether I'd be wise to adopt this pattern (if it is one...)?
Update
Since Jeffrey Palermo replied to this question I see that in the (work-in-progress) manuscript for MVC2 in Action this pattern/style is discussed and illustrated using a Factory that is used to locate a Repository in order to keep the domain layer ignorant of persistence concerns. (see chapter 23).
By default the use of this factory throws an exception:
"the knowledge of how to create the
repository doesn’t reside with the
factory. This factory merely
represents the capability to return
the repository"
The example could have used one of several mechanisms for initializing a concrete implementation of the repository interface. In the example in the book they elect not to use an IOC container for sake of simplicity and provide it explicitly in some start-up logic.
"The important thing is that neither
the Core project nor the UI project
should reference the Infrastructure
project or libraries that are purely
infrastructural in nature. We have
kept NHibernate completely off to the
side so that the rest of the
application doesn’t care how the data
access is happening"
A final point to note about the example code in this new chapter is that the Factory is no longer static (at least not as far as the externally facing interface is concerned).
Update 2
Mr Palermo blogged some more about this particular style of Abstract Factory (see the implementaion of OrderShipperFactory).
I could also just consider 'Manual Dependency Injection' (Uncle Bob).
Update 3 - March 2016
There's another example of it here, though Jeffrey is explicit about this being demo code, and the comment indicates that this would be configured in what Mark Seeman would call a Composition Root (i.e. at Application Start-up)
I discovered this in Jeffrey's article "Onion Architecture: Part 4 - After Four Years"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好问题。我也不喜欢它。它确实应该命名为“StartupFactoryConfiguration”，但它在重构列表中。
我们尝试了这个想法，作为一种为不通过容器进行构造函数注入的地方设置 DI 的方法。
它会消失。我不知道反模式是什么（什么名字？），但 StaticFactory 会死掉。
现在，从今天早上起，它已更名。现在是 AbstractFactoryBase。它是抽象工厂模式的实现： http://en.wikipedia.org/wiki/Abstract_factory_pattern< /a>
工厂的实现最终会调用 IoC 容器，但它允许从代码中的某个位置进行访问，而无需对 IoC 容器程序集进行程序集引用。
问候，
杰弗里·巴勒莫
Good question. I don't like it either. It should really be named "StartupFactoryConfiguration", but it is on the refactor list.
We played around with that idea as a way to set up DI for places that were not under constructor injection via the container.
It will go away. I don't know what the anti-pattern is (what name?), but StaticFactory will die.
Now it has been renamed as of this morning. It is now AbstractFactoryBase. It is an implementation of the Abstract Factory pattern: http://en.wikipedia.org/wiki/Abstract_factory_pattern
The implementation of the factory is to end up calling an IoC contrainer, but it allows access from a place in code without an assembly reference to the IoC container assembly.
Regards,
Jeffrey Palermo
任何静态的东西都是 DI 的敌人。
此 StaticFactory 看起来像是 服务定位器（反）模式的实现。
我认为服务定位器是一种反模式，因为它对于 API 的用户来说是完全不透明的，哪些依赖项需要就位；因此，人们可以轻松地在服务定位器将抛出异常的上下文中调用对象上的方法，而 API 绝对不会给您任何线索表明情况确实如此。
适当的 DI（例如大量使用构造函数注入）是一个更好的选择。
Anything static is an enemy of DI.
This StaticFactory looks like an implementation of the Service Locator (anti-)pattern.
I consider Service Locator to be an anti-pattern, since it is totally opaque to the user of the API which dependencies need to be in place; thus, one could easily invoke methods on objects in a context where the Service Locator would throw, and the API gives you absolutely no clue that this is the case.
Proper DI such as copious use of Constructor Injection is a much better alternative.