Let me state up front that I am currently morally opposed to DataBound controls. I can't say that I have good reason for this, I just prefer the greater flexibility of doing things myself. However, this may cost me somewhat in ease-of-use.

In the past, when I worked on DB using programs, I generally had the luxury of knowing that only one person would be using the data at any one time. This is a great simplification, as there are no scalability issues.

Right now, I am working on some of the same types of things in .NET, though there is a larger Read-Only app looming on the work horizon. I got thinking about how I wanted to handle the data management in the current program, with some consideration of extending the design to new programs that are currently unconsidered. That's what this thread is about.

I came up with a design where the database is encapsulated in a class. Originally, the connection itself was a class within this class, but I have scrapped that idea as valueless. The obvious reason for doing this is so that the implementation of the class can be changed without altering any other part of the program. However, this means that other parts of the program have to be insulated from the DB class.

The next part of the design, was to make classes for each table in the DB. Naturally, once I started on this, I finished it without thinking it through very carefully, and many of the classes turned out to have no purpose in real-life. Mendhak pointed out an add-on from MS (I think) that does this sort of thing, so I guess I wasn't totally crazy.

My intention was that I would have a function in the DB class that took an two arguments (or more if needed). The first argument was a criteria, while the second argument was a class passed in ByRef. The function would return the record that met that criteria, and fill the class. This might include multiple joins, or none at all, but the DB class filled the data class. The data class was then used by the form to populate controls.

An empty data class would receive new data, and do any manipulation necessary on it. Then the data class could be passed to a function in the DB class that would perform an UPDATE/INSERT on the DB.

It also occured to me that I could make a container class that could hold an array of data classes. Then it dawned on me that this would effectively be a dataset. Whereas a datareader is a forward-only data mechanism, the dataset is a bi-directional datareader. That is what my container class would be, as well.

This lead me to the question in this long post: Am I nuts?

Am I just re-inventing something that is already available? I really like the idea of a dataclass to encapsulate the data moved through a form, but perhaps the whole idea of populating data classes from the DB is overblown.

The reason I ask is that for an earlier project, I devised a data description language. A couple years later, I realized that I had re-created SQL, and my language could be converted into pure SQL in a single pass. The only advantage to my language was that you could create proper english sentences out of my language faster than you could from SQL.

I'm looking for any suggestions here. I enjoy coming up with odd designs, but I fear that I am duplicating what is already there.