Hi Mark,

No, it's not archaic ... it's the way that a lot of people use Business Objects (I'm not one of them, but that's neither here nor there <g> ... I databind my controls to DataSets/DataTables rather than to Business Objects).

So, if you're comfortable with the Business Objects methodology, there's no reason not to extend it into .NET. There's really no right/wrong way of doing this kind of stuff.

~~Bonnie



>I have been working with .NET, and am considering creating our own business objects to manage data.
>
>I am moving from VFP, and developed a business object class many years ago that has served us really well and wondered if it made sense to duplicate this methodology, or if there was a better method in .NET.
>
>Our current methodology in VFP is quite simple:
>
>We SCATTER a table structure from a table to an object; thisform.oData
>The forms then use the properties from this object; ControlSource = "thisform.oData.cName" for example
>When we save, we use ADO to take these property values and using parameters send the data back to the database.
>
>Is this method valid now or is this really archaic?
>
>Cheers,
>-Mark