I would tend to agree, If you've got 40 odd fields and that's not
going to change often, then I'm with Jon, but if you need uber
flexibility you could consider the following. Depending on your
validation needs you could very easily put all the detail into a
config file.

Silly example but something like:

 <id ="1" field name ="LastScanned" type="System.DateTime"
required="false">
   <validate minvalue="01\01\2000"/>
 </field>
 <id = "2" field name ="OSType" type="System.int32"
enum="MyApp.OSTypes">
   <validate enumcontains="true"/>
 </field>
 </field>
 <id = "3" field name ="Name" type="System.string">
   <validate maxlength ="50"/>
 </field>

You then read all the field info in at start up bung them in a
hashtable (perhaps create a field class and populate the various bits)
and in your setvalue, a) retrieve the field by name (or an ID). If it
doesn't exist, throw exception, else get the field object and pass
that with the new value to a generic validator that understands the
validation rules defined in the validate section. For OSType I've gone
for an enum, but it could just as easily be a table name with look ups
or a web service address, etc.  Because the type is listed you can do
a cast to ensure types are adhered to.

There are pro's and con's to the above, it really depends on how
frequently you're going to be adding/deprecating/renaming fields. It
does offer some flexibility in that you can expand the above to
include UI information for example. Should this be a combo or a
listbox? But there's an overhead setting it up. I've used similar
schemes successfully, but we needed such a high degree of
configurability it just made sense.