[RESOLVED] Proper persistence in an object orientated world

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?

Form A create class DC .... Form A then passes class DC to Form B.... after that Form A doesn't care what form B is or what it does... even if DC was passed by val, only the ADDRESS of DC was passed as a copy... but it still points to where DC resides on the stack. So even if Form A goes out of existence at this point, DC won't be GC'd since it's address is still being referenced by Form B.

-tg

This still leaves the issue of FormA needing to know about FormB, add more and you have chaining, remove one and it falls apart.

I would have imagined that both should reference a single shared instance which would then instantiate its own internal data stores (static objects don't seem to be capable of working with instance data, or am I wrong?).

Your way is how I would have originally did it but its very brittle and cannot be used with different MVx patterns, which I have been playing with and tend to offer greater clarity in larger programs.

I guess it depends... what spawned Form B? if both need access to the same data, and neither is dependant on the other... then the data has to reside some place where both forms can get to it. Here's how we've dealt with it - we have a shared class that contains shared instances of all of our datasets.... the datasets are then exposed through properties, with the appropriat is nothing check, and instanciates it if needed before returning it.

-tg

Yeah that is closer to what I am looking for but you mention data sets, are these saved to a database? This is the gotcha, as the DB resides outside the application it bypasses the issue I am having which is storing the data in an object within the application.

you lostme... how is it any differernt? Doesn't matter where the data comes from... we use datasets because it's an enterprise app, and pulls data from no less than 12 locations. We've got a number of screens that use some of the data from the different datasets.

Are you dealing with static data? Same concept applies. Same solution, different project, we store all of our string resources in one single assembly. Then expose static read only static properties for each of the strings we have in the resource. Since all projects reference this project, we can get to any of the strings, any where, any time.

-tg

The data is not static, that is where the issue lays. It is generated by the user at runtime. Your data sets read from an outside source right, thats the difference. I am trying to understand how to keep the data source inside as an object of some sort that isnt static.

so your data is still coming from an outside source... your source just happens to be the user, rather than a database. Same deal... you just need a simpler startic class than what I use. But I think the concept still applies. So your dataclass is static. Form A reads the data from the user by what ever means it needs to, then puts it into your dataclass. At what everr point Form B is called (assuming the app hasn't been shut down), the data would be in your DC. Since it is static, it won't be disposed until the application closes. That means it's still available to Form B. Form B can then make what ever changes it needs to do. At the same time, if Form A is reopened, or even remains open, it will have access to the updated data.

-tg

I guess your right!

I was under the impression that data cannot be written to a static class though?

It most certanly can... that static class I mentioned? Only half of its properties are datasets... the other half are simple types (string, integers, etc) ... and it's got a couple dozen functions and methods to boot.

-tg


When I mentioned static, I meant shared... in C languages they are called static.... in VB it's calles shared.

Cool, I will digest all this and try out some samples!

Thanks a mil!

Ok after some playing around and following your idea's I cam up with an example that suits what I need to do:

Code:

---

namespace TesterApp
{
    public class DataStore
    {
        public string Name { get; set; }
        public string Surname { get; set; }

        public void ChangeName(string FirstName, string Surname)
        {
            FirstName = this.Name;
            Surname = this.Surname;
        }

        public void CommitToStorage()
        {
            DataStore.InternalStore.Name = this.Name;
            DataStore.InternalStore.Surname = this.Surname;
        }

        public void ReadData()
        {
            this.Name = DataStore.InternalStore.Name;
            this.Surname = DataStore.InternalStore.Surname;

        }

        private static class InternalStore
        {
            public static string Name = "";
            public static string Surname = "";
        }

    }
}

---

As you can see the class can be instanced which satisfies my requirement of each GUI object not having to be aware of the other for references. The issue of ownership is also resolved as the DataStore logically owns its static internal store. Of course it would do well to have this store in a partial for readability but unless someone objects to this style I think it is the one I will use.