title: Is my singleton design less elegant than it should be? What's the best practice?
body: <p>I'm currently building a tool for my game engine using WPF. The tool is project-centric (think Visual Studio, XCode, etc.) and allows the user to edit one project at a time.</p>
  
  <p>Currently, my implementation hosts a singleton instance of the project class, <code>ArchitectProject</code>. This is available to all other components as a property on the singleton class. I feel like this implementation is a bit of a hack and not as neat, simple or elegant as it could or should be.</p>
  
  <p>The <code>ProjectManager</code> class, a singleton class within the host application, provides global access to a <code>Project</code> property. Various other properties and methods are exposed, mostly supersets of versions in the Project class but using <code>ProjectManager</code> properties for efficiency.</p>
  
  <p>This feels really, really wrong to me. First and foremost, the static constructor initializes a new Project instance from the start so that WPF doesn't complain about null references when setting up the data binding. There are multiple controls and other components that require access to the current project instance, especially those that are data bound to its properties. Further complicating the data-binding situation is that whenever a property value is replaced with a different instance (e.g., loading an existing project, creating a new one), all WPF data bindings are lost, so additional events and other extra crap are required to ensure each control's data bindings persist properly.</p>
  
  <p>Secondly, the result of making the current <code>Project</code> instance globally accessible is a bunch of related hackery to get the implementation to work properly. Everything in my un-professional gut is telling me I'm doing more work than I need to, and I'm doing it completely wrong from the start.</p>
  
  <p>I suppose my question, at last, is <strong>how should I go about implementing a globally-accessible property within my app?</strong> I've always liked the notion of programming everything as though you're writing an API. If a developer wanted to hook into my app, the required hacks and extra steps to get everything working would not be immediately apparent, and that screams poor design to me.</p>
  
  <p>Ideas?</p>