Is the StaticFactory<T> in codecampserver a well known pattern?

Question

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).

Answer 1

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.

Answer 2

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%5Ffactory%5Fpattern

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