Collections and Configuration files

Collections and Configuration files

• Oscar Marquez

  In general it is a better practice to use Classes which are reference based over structs which are value types.  Interacting with a class and moving it between method calls always provides expected behavior.  Structs are value based and as such always copy by value. 

  Its very easy to use a struct in place of a class and end up with unexpected behavior.

  Structs have a large amount of use in the framework mostly when working with platform API through P/Invoke.  For all other uses I would recommend using a class.

  
  
  

• Mayank Srivastava

  Putting the values in an app.config file is useful if you wish to use .NET's ability to merge app.config settings with machine.config (and enterprise configuration). 

  Its also highly useful if you are writing a web application as ASP.NET will monitor the web.config file and reset the web application when changes are made to the file.

  Other than those two scenarios, there's nothing wrong with using a custom xml file for configuration.

  
  
  

• Louis Davidson - SQL Server MVP

  With .NET 2.0 you can create a custom ConfigurationElement and ConfigurationElementCollection to handle the storage and retrievalof values from the config.
  
  

  public sealed Foo : ConfigurationElement {    private static readonly ConfigurationProperty s_bar =       new ConfigurationProperty("bar", typeof(string), null,           ConfigurationPropertyOptions.IsKey);    private static readonly ConfigurationPropertyCollection s_properties;    static Foo()    {       s_properties = new ConfigurationPropertyCollection();       s_properties.Add(s_bar);    }    protected override ConfigurationPropertyCollection Properties    {       get        {          return s_properties;       }    }    [ConfigurationProperty("bar", typeof(string))]    public string Bar    {       get { return (string)this[s_bar]; }       set { this[s_bar] = value; }    } } ... [ConfigurationCollection(typeof(Foo))] public sealed FooCollection : ConfigurationElementCollection {    protected override ConfigurationElement CreateNewElement()    {       return new Foo();    }    protected override object GetElementKey(ConfigurationElement element)    {       return ((Foo)element).Bar;    }    public void Remove(string bar)    {       BaseRemove(bar);    }    public void Add(Foo foo)    {       BaseAdd(foo);    }    public void Clear()    {       BaseClear();    }    public Foo this[string bar]    {       get       {          return (Foo)BaseGet(bar);       }    } }

  
  
  

• Paul Smith

  I have the code done to write and read my collection as an xml file.  Is there anything to be gained by putting it in app.config   The code to write out to the file is minimal, honestly, and I can have a specific app to edit the values in the collection.  What would I really benefit by having the config in the app.config file   Maybe a pre-written configuration editor
  

• jwalling

  Thanks, that helps a lot. 
  
  I have another question I've just stumbled upon that you may be able to help with.  As for design considerations, my collection is a bunch of objects, obviously.  I can use structures or classes to populate the collection with.  My child objects don't really have any methods, just properties.  Are there any best practices or anything to be gained by doing structures vs. classes  
  
  Its really screwing around with my head that it appears structures can have methods...  (all this is being done in VB.Net for reference.  It doesn't appear that Structure (vb) = struct (c#).
  

• Mindking

  I usually recommend you wrap fields with properties when working with a class.  Fields cannot be the target of data-binding (in asp.net or winforms).

  If you're using VS2005 you can very easily convert public fields into public properties with private backing fields by using the Refactor / Encapsulate Field feature.

  There's nothing wrong with exposing fields on a class but usually its best to keep those type of classes internal to your application.

  
  
  

• Vojtech

  Is there anything really wrong with declaring all members of a class public from a design perspective   The class in question would really just be used to store a list of values.  It will have quite a few different values, 33 to be exact.  Writing and maintaining properties for each one of these would be a huge pain.

  
  
• Collections and Configuration files