Where to put Application scope components in Winforms?

Question

Where do you store application scoped components in your winforms apps? I see that I can create a descendant of Component in my application. I could then drag and drop the components that I want to share among the forms in my project. Is this the best practice for shared access to components (non-visual controls)? In Delphi, we had a DataModule. A DataModule was a simple design surface that functioned as a container for non-visual components. I would drag and drop Data Access objects onto this surface and access them from all forms. It provided a nice central location and cache for my data objects.

How are you guys doing this in Winforms?

Answer 1

I normally use a singleton for things like logging classes, database adapters, etc. This is handy when you want a static reference to your objects throughout your application.

I may have misunderstood your question, though.

Answer 2

There are many ways to achieve "application scope" objects and data for an application. However, it might be useful to determine which of the shared "components" you need access to are actually just global, or whether some of it is actually "contextual". There is a difference, perhaps subtle in some cases, between global and contextual components.

In the case of a utility, such as a logger, that is most useful as a global facility, as logging is one of those pesky cross-cutting concerns. However, in a lot of cases, information is specifically contextual, and deserves to be wrapped up in a context object of some kind, only accessible to code that is actually executing within that context. Context can be difficult to identify at times. If you can identify it, and you can figure out how to initialize and make available a context object at the right times to the right code, you should end up with a better product that has more appropriately organized code than if you just make a bunch of data globally accessible.

I recommend looking into BDD, Behavior Driven Development, a methodology that blends agile and TDD practices into a more strict development methodology where context plays a critical role.

Answer 3

System.ComponentModel.Component provides a design-surface for non-visual components in Visual Studio. Usually, in your project, you can just "Add" "Component" and start adding and configuring non-visual components as you can with the designers for forms and user controls.

For global access (application scope) you could provide access to a component in your Program class as a public (or internal) static member.

You can initialize this member in the Main method, or by arbitrarily complex interaction between Program and MainForm or other components, e.g. using the service infrastructure stipulated by the related classes in System.ComponentModel and a customized implementation of IContainer.