>>I also don't like all the stuff VS.Net spits out when all I'm really after is code that handles the fields of a table.<
>
>I've been using my business objects to do this. I create business objects with properties that (more or less) match the fields in my tables. That way I can pass around business objects rather than datasets and that takes care a lot of the work - what a concept,right? :)
>
>Still, the business object uses the raw items from the types/untyped dataset and when it comes to binding to controls I still fall back to the underlying dataset.

Yeah you can do that easily enough, but it gets to be even more of a maintenance nightmare <g>... because now you have to keep everything in sync manually.

I've been thinking about this today and did a little playing around. One idea I had was to create a more light weight generator that just generates a shall we say 'Row Container'. You pass it a datarow and then the RowContainer has the fully typed properties for the fields.

Still is code generation and it overlaps somewhat with what the XSD stuff does, but the advantage is that you can control this more easily. In fact, it would be easy to build a builder that lets you spit out this stuff by selecting a Database, or a set of table to generate these rows for. The code for this would be much, much leaner than the dataset stuff generated and would only be used when you actually assign a row to it.

I hate reinventing the wheel but if I look at it in terms of overhead this makes a lot of sense of keeping things lean...