Variables Or KeyValuePairs

It depends on the situation, but its certainly an option. The downside is that the HashTable will store everything as an object (or string if you use the specialized version), so you will have to cast each value when you retrieve it from the HashTable and return it from your property.

So, unless you are only storing strings then its probably more trouble than its worth.

Hi there, Thanks for the reply, I can see what you mean.

I personally don't like the idea, i find it much easier, and tidier to use members and properties, however i'm after scalability.

The argument the guys at work have is that if you were to add a field into your database you would need to change your code etc etc to suppose that field, so a hashtable is ideal.  I am in the frame of mind that if the database was right in the first place additional fields shouldnt be that frequent, but its always a possibility i suppose.

I'm torn between the 2 to be honest....i'll see what anyone else has to say before i close

Thanks again

This is probably a situation where you should be using interfaces. You create an interface for the initial version of the class, then if you add new propeties at a later date you simply create a second interface with the new properties. That way you don't "break" any client that relies on the original version.

i see, so if i use an interface, do you mean to use it in conjunction with the hashtable so i can access everything via property. And if i create a second version, have the new interface have the same properties as the old one plus any additions?

Thats a good idea, i have implemented some interfaces at the moment - but i think that this suggestion could solve many problem!

Thanks very much

I would go with the interfaces, but not the HashTable (unless you are using purely string data). Plus you are always going to take a slightly bigger performance hit using a HashTable than you would using built-in types.

>> And if i create a second version, have the new interface have the same properties as the old one plus any additions?

Even simpler, have the new one derive from the original, plus the new properties:

   public interface Shape
   {
        double Width
        {
            get {}
            set {}
        }

        double Height
        {
             get {}
             set {}
        }
   }

    // new interface, extends original
    public interface Shape2 : Shape
    {
        double Diameter
        {
            get { }
            set { }
        }
    }

As i see, i do like the idea of using inteface, as i was always told this was good practise.

I agree that hashtable would prob hit performance, however the reason i was told to consider hashtables was because i could easily add variables to an object, simply by adding a key/value pair to the hashtable within that object, so its scalable in the sense that i would not need to bebuild the app and implement it every time i add a field. i would just add it to the hashtable and 'theoretically' that object now contains an assigned variable.

I aplolgise for naivety as i'm an not expert on interfaces, but if there a way i could use interfaces to implement a similar solution that hashtables provide above?

>>>Even simpler, have the new one derive from the original, plus the new properties

Genius! :o)

How would you go about adding the new value to the HashTable without changing the code ? How would the rest of your code know it was there in order to retrieve it ? If you added it via some sort of config whats to stop anyone else adding rogue values ? How would you app be able to alter the value, and how would you prevent it being set to an invalid value ? Would your HashTable be read-only ?

If you added a new value to a HashTable dynamically without modifying the code you would have a hard time treating it as the correct type.

I see what you mean, however the app in question is a data trafficing application.

it has a client on the application and server.

Data is retrieved from a stored procedure and it added to an object,
the object then converts its properties to xml and passes down to the app sitting on the clients machine
which then creates a summary report depending on the xml passed down to it.  
At the moment i use reflection to retrieve a list of variable names within the object and their values for the xml conversion, and i am happy with it. however i can imagine it would be easier with hashtable

However i ask this question, not only for this task, but also for future devewlopment "Do's and Dont's".

I am against using hashtable as variables and properties are there for a reason and i refuse to believe that it is better practise to use hashtable - which is why i ask question.  But i agree with the interface advise, i understand your point above, and was kind of expecting it :o)

As long as there is not something magical that interfaces can do, i think i have gained what i came here to gain from this thread. :o)

do you understand what i mean above?

Thanks you very much for your participation

Thats a good Rule,

Thanks for your help, thats some good advise

Apresto