I was generally in the mood to avoid code repetition. This was 5 years ago. I was using ADO.Net (I probably didn't give that impression with the code I used. I forgot the exact method names and such. The example I used was pseudocode), I had DataSets, as I recall, so I was extracting out DataTables, then Rows from them, and then selecting out fields. So the issue was I was using Microsoft's framework. I think to really have made this better, I would've needed to subclass off of Data Set and DataTable, and produced my own custom Row type out of that, which would've required internal access to Microsoft's ADO.Net data structures. There was a tool at the time (probably "Reflector"), now that I think about it, which I guess I could've used to decompile Microsoft's code, but there's no guarantee I would've been able to pull this off even with that, given that they could've closed off access to their data structure to subclasses. With a modern version of .Net this would be more doable, because I could just add some class extension methods, and (probably) have access to the internal data structures (though that's still a question in my mind). I didn't think of doing this at the time, as I remember I was already behind schedule with that project. It took a while to write the code I did, but it didn't take a lot of learning time to pull off. As I recall, I did some cutting and pasting of code (which I would then go back and revise for specific field names and such) to help save time.
Like I said, this gave me perspective about why some developers preferred to work in a meta-language, which would generate C# code, or what have you.
The answer is, yes, I think there *might* have been a better way to pull this off. The issue was time.
Keep Up with TechRepublic