Dittos to what Masem says. This actually looks like the first system I designed immediately after reading some OO books. (In this case that is not a complement.)

This is a bit of an over simplification, but the design should be for change. Installed applications change, and requirements change over the development cycle. Change should be easy. So if a SQL table changes (column add/change/remove), or the tables are completely redesigned, how easy is it to change the application?

If a simple table change causes changes in all most of your layers that might indicate a design problem. I like the idea of generating columns lists from the db, but is it done at all levels?

Having a new column automatically added to an INSERT statement is great, but is it automatically added to the web form? If so, is the layout what you want? If not, how does the database ever get a value? And do you want to be automatically generating column lists in one part of your application, but not others?

To make a long story longer, given that it is in place already, the added complexity probably won't hurt you as long as you have the ability to hand-code the SQL statements that don't fit neatly into the schema. I actually do something similar for the maintenance part of my apps that only admin users see. But for end-users, presentation and details matter so much that hand-coding is more normal.