Hi guys,

This one is a doozy. I, as some of you may know, have been studying for various MS exams and trying to put a portfolio together. Some of the ideas I have for applications are based on different scenarios. One of the current applications I am working on deals with persistence in object orientated design.

Persistence to an outside source is fine. For instance user settings can be persisted to a database, XML file or even a serialized object. My issue comes from understanding persistence to an inside source. I think the issue is the fact that an object can only live as long as its caller lives. This connection is what is causing the issue.

For instance consider an application that has a form called FormA. This form has some data that is only useful in the context of the life of the application, or more specifically each cycle changes the context. FormA has two strings, Name & Surname. FormA passes these two strings down to a data store. This is a simple class that has two public properties to get and set the strings.

This sort of application is one a lot of people are familiar with. Most people, rather than work on data in the form code-behind will send the data of to a class to store or process. This brings up the first issue of persistence. The "data" classes instantiation is "owned" by the form that calls it. This is not an issue now but will become an issue shortly.

Lets say we introduce a new form, FormB, this form takes the first name & surname and makes an anagram. This presents a problem. FormA contains the reference to the "data" class and my have already been garbage collected by now. If it hasn't we can pass a reference to the data class but this means that FormA must now about FormB and FormA must stay in memory as the "data" classes owner. Also passing the value by reference still causes the first issue plus synchronization issues.

So what is the correct way to do this? I have looked at singletons and they seem to be overkill. They give a reference to the "data" class to everybody. Is there something in the framework I am overlooking? How is this normally overcome?