IProjectModel sounds like it contains data--i.e. it's not a pure service.
Consider modeling it like you would model a service that was backed by a database, but instead of connecting to a database, use some in-memory construct. It's probably as simple as a static member variable on your service implementation. Something like:
public class ProjectDataService : IProjectDataService
{
private static IProjectModel _projectModel;
public IProjectModel Create(string fileName)
{
if (_projectModel == null)
{
//create it
}
return _projectModel;
}
}
(Note that you you may have to do some locking of the member variable.)
Now if you need to switch to having multiple projects open at once, change your member variable to a list structure (IList, Dictionary, etc.).
Edit based on your comment.
I'm referring to once it's already been created. The big idea behind IOC seems to be "let the container handle the dependencies", and it seems Windsor could support this, I just don't see how. I'd like to specify IProjectModel in a transient object's constructor, and have the container resolve the current IProjectModel, if there is one. Your answer is a lazy singleton, which isn't what I was asking for.
What I'm saying is IProjectModel is not really a service--it's state/data. So injecting it directly doesn't make sense (at least not to me). Wrapping it in a IProjectModel data service or IProjectModel "state manager" is more in line with injecting services, which is what DI frameworks generally do.
Can you register an IProjectModel? Yes. However, container registration is generally done at application bootstrap time, not based on user input. Also, from your description, you may need to support multiple instances of IProjectModel. How would the container know which instance to give to you when you ask for it?
As a more obvious example: would you consider injecting a string or an int in your constructor?
Let the container handle the dependencies is not exactly how I would describe the "big idea" behind IOC. It's about decoupling from (or handling) service dependencies. So if you want to inject something that is stateful, I'm suggesting you wrap that state in a class that can be injected like a service.