I can't find a better name for what I'm trying to do, so screen collection would do, although it is not the name of the pattern Jeremy Miller is using in his "How to implement your own CAB" series.
What I'm trying to do is to have a separate ScreenConductor class which controls the showing embedded views / screens in a WinForms app. The ScreenConductor knows to ShowShell() for example, and there it decides if the Shell is hidden or not, initializes the default view in the shell etc... Now to do this ScreenConductor has a dependency on ScreenRepository, which in turn has methods GetShell(), GetScreen1(), GetScreen2() etc <- and how I imagined it, it will have a method to return every screen of the app.
Now, lets say I want to inject these "screens" here: I can do service locator style (IoC.Resolve<SomeScreen>()) or I can have constructor injection for these views (or setter injection maybe better, but that is not the point). What I'm asking is some advice if I'm moving in the right direction with this, the app is not terribly complex, I know all the views statically, this isn't some tabbed MDI document application or something.
I think I see where you are going with this and it is certainly the right approach.
As long as you implement each Screen as an interface, which all inherit from the same root interface then you should be good, for example:
interface IScreen
interface IShellScreen: IScreen
etc.
ScreenRepository should return types of IScreen (in fact you could make use of the generic repository pattern) which I would cast in the ScreenConductor.
Then it is up to you - you can either use an IoC container or you could DI directly into the constructors.
It is complex but if you design it this way then you know it will scale - I wouldn't do this for an app that had 4 forms but one with 400 would definitely need this approach!
HTH Duncan