SQL Table Interface Class

[RoguePoet01]

Hi,

I'm just learning C# and I found it could do some things that really blew me away. I look forward to using these features for other things in the future, but I was thinking about using them here at work, first.

Say we keep track of cars, trucks, and motorcycles.

Each has its own table.

I'd like to make an object that serves as an interface for each table, so I'd send it something like

objCars("Update", recordset)

or

objTrucks("Add", recordset)

Ideally I'd be able to reuse this code and call it from any program.

Is that a good idea, or is that already being done in the .NET interface.

 

[DonQuichote]

Just to order my own thoughts, I wrote an article on the subject of persistent objects You can find it at:

http://huizen.dds.nl/~w-p/article/wrtabrec.htm

If you want to call it from any program, ideally you would hide the recordsets inside the classes you write. "Recordset" is a very generic type, while the recordsets you expect as parameter are probably very specific. If you only have a "Trucks" collection containing "Truck" objects, the interface documents the whole use of the objects. Furthermore, you will not get errors because of passing wrong recordsets.

Best regards

 

[RoguePoet01]

Thanks for your reply.

I'm just trying to figure out a way to simplify my SQL transactions.

I thought by devoting an object to dealing with a given table, that might help.

So objTrucks would contain methods for adds, updates, and deletes. It would have a "type" variable (for lack of a better word) that would be like:

With Truck
.TruckIndex
.MainIndex
.year
.color
.miles
.condition
.etc
End With

This type would exactly mirror the SQL table. If a value is empty, it would be set to null.

I'm betting that something like this is being done all the time, but I've yet to try it. I've had to write add/update/delete routines for the Truck table in each program I've written and it just seems like there ought to be a better way.