Develop Reference

Using classes with forms

I'm trying to understand whether or not it is correct to use a class when entering data into a form. I am unsure whether my understanding is correct, I don't know if I should be trying to create a new object when entering the data, or if my data should be stored in an array/file etc.
This is just for my understanding, I am just learning for myself, so don't have a specific example of what I'm trying to achieve. I am trying to understand classes, and when to use them, currently I'm messing about with c# forms in visual studio
lets say, I want to enter information into a form of all of the members of my fishing club, i.e. name, address, contact info etc. should I be attempting to create a new object of a class that contains methods for getting/setting these variables, or should I be storing these details somewhere else, in an array, or write them to a text file/excel file for example? As I'm new I think I'm struggling with the concept of classes and where to use them.
I expect that to use a class for this purpose I would have to learn to create a class instance at run time in order to create multiple instances of a class, whereas entering the data into an array I would just need to initialize the size of the array.
I'm a bit lost so any help would be very much appreciated.

Should you store those fields in objects? Yes
Should those objects be stored in a collection (like an array)? Yes
Would persisting that collection to a file make sense? Yes
Basically, you are asking to choose an alternative among things that aren't really comparable, much less mutually exclusive. As the comments suggest, make sure to read up on object oriented programming, but here's a quick explanation of each of the above:
Objects provide a structured way to store information (giving each field a name and a type, for starters) and a way for the language/compiler to enforce that structure. Storing all the related data for an entity in an object is a great idea, you almost never want to have a bunch of members for that purpose.
Arrays or more generally, collections, are groups of "things". You could have stored all that information in an array instead of an object (and then for multiple records had "parallel" arrays" but this is a very messy and amateur technique). A collection of your objects however, is a totally reasonable thing to do (you don't want object1, object2, object3 variables in your code).
Files are important because both objects and collections (which are, in and of themselves, objects) are stored in memory, they will go away when the application closes. Files (and similar, like databases) give you a way to persist them (hence such techniques being referred to as a "persistence" layer). You can then load the persisted data into a new instance of your program (say if the user restarts the computer).
Side note: Should I make methods for getting/setting these variables? No.
Just use properties (ie, public string Address {get; set;}). They provide both a backing field (at least with an auto property like the above) and are syntactic sugar for both get and set methods (which you can override with a "full" property).
As a bonus, if using WPF you can automate the population of properties from UI with data binding, but that's a question for another day :).

C#: Save serialized object to the text field in the DB, how maintain object format versions in the future?

I've complex object (nested properties, collections etc) in my ASP.NET MVC C# application. I don't need to save it into the multiple tables in the DB, serializing the whole object and store it like a whole is ok.
I plan to serialize the whole object (in something human-readable like JSON/XML) and store in text field in the DB.
I need to later load this object from the DB and render it using strongly-typed view.
Here comes the question: in the future the class of the object can change (I can add\remove fields etc). But serialized versions saved into the DB before will not reflect change.
How to deal with this?

You should write some sort of conversion utility every time you significantly change structured, serialized messages, and run it as part of an upgrade process. Adding or removing fields that are nullable isn't likely to be a problem, but larger structural changes will be.
You could do something like implement IXmlSerializable, peek at the message and figure out what version the message is and convert it appropriately, but this will quickly become a mess if you have to do this a lot and your application has a long lifecycle. So, you're better off doing it up front in an upgrade process, and outside of your application.
If you are worried about running the conversion on lots of records as part of an upgrade, you could come up with some ways to make it more efficient (for example, add a column to the table that contains the message schema version, so you can efficiently target messages that are out of date).

As long as you're using JSON or XML, added fields shouldn't be a problem (as long as no specific version schemas are enforced), The default .net XML serializer for instance, doesn't include fields that have their default value (which can be set with the System.Component.DefaultValue attribute). So the new fields will be treated the same as the omitted fields while deserializing and get their default values (default class values that is, the DefaultValue attribute only applies to serialization/designer behaviour).
Removed fields depends on your deserialization implementation, but can be made so that those are ignored. Personally I tend to keep the properties but mark them as obsolete with a message of what they were once for. That way when coding you'll know not to use them, but can still be filled for backwards compatibility (and they shouldn't be serialized when marked obsolete). When possible you could implement logic in the obsolete property that fills the renewed data structure.

Need WPF XML Binding Advice

I have a C# WPF program that needs to display GridView and 2D graph data which initially will come from a hardware device. I also want to continuously (or frequently periodic) backup this data to an XML file on disk. What would be the easiest way to implement this in visual studio? Should I create an XML schema first, or use the dataset designer? Should I bother with datasets at all or would it make sense to eliminate them and write my incoming data directly to xml?

I would recommend:
Plan a structure of an XML ahead. Create a simple empty file to help you along the way.
Create a data serialization provider as well as the interface that it will implement. In your case it will be an XML provider (who knows, you may need to save the data to a database in future. You should plan ahead for that.)
Write a custom class that serializes your poco domain objects into an xml using LinqToXML.

CSV data (unkown format) to XML data (fixed format) via business classes. Is using reflection a good idea?

I am working on a library that builds fairly large XML files (e-commerce offers).
I use business classes (such as ProductInfo, PriceInfo etc.) and I generate the resulting XML out of these.
My latest task is to implement functionality that allows to generate this XML out of CSV input files.
The CSV files do not have any predefined format and it is user's task (we provide an application that allows them to do that) to map all the CSV columns into their respective counterparts in our fixed XML format.
So basically their job is to assign each column to one of my bussiness classes fields: "all data from this column goes into ProductInfo.ShortDescription etc.".
Our format is likely to change in future - it keeps on being updated and extended - and so I would like to make my implementation as generic as possible.
The solution I considered is following:
the library returns names of all the available / required fields
our user maps CSV columns to those fields
I implement a custom attribute (containing a field name - string) and mark all the fields in my business classes with it. So once they've mapped all the columns and submitted the data in CSV, my library starts creating ProductInfos etc. assigning input values to fields, identified by the attribute name. This would be done by reflection.
Is this a good idea? I have some concerns regarding performance (I know that reflection is slow), although I'm not sure how much of an issue that would be. Is there any other issues I should be aware of? Are there any better alternatives?

Why not just set up a web service to handle these for the end user? If you make changes to your business objects, which are exposed through the service, the schema for the WSDL service will automatically update. This will give you the ability to strongly type your data through a schema automatically.

Saving file system metadata

I want to save all the metadata connected to a file system, but not the "useful" data. The metadata should be available for viewing even when the original files aren't.
I first thought that I could accomplish this by serializing for example a DirectoryInfo object, but I now understand that the object doesn't actually save the data but rather merely saves the path and accesses the file itself when the methods are called. Thus serialization would be worthless, since the deserialized object would look for the file instead of "remembering" the metadata.
So: is there some kind of built in framework class for doing this or should I just implement it myself?

This object is an object hierarchy so it could get a bit tricky to serialize? You might try creating an a simple object to model the data you want to save. You could then use AutoMapper to copy the data over into the DTO-like object and then serialize that. This way if you wanted to actually persist the entire tree of data you could without writing much code.