Aaron Trevena wrote: > it's the scattering of SQL all over the place that requires changing > by hand when the schema is updated or code is refactored, etc.
I'm curious, as a non-user of these classes - how does a schema change not get reflected in how you have to call the classes? It seems to me that simple schema changes like adding a column or changed field sizes don't require any change to SQL either - if you wrote it sensibly. Similarly, classes which do some abstraction will also have some schema changes which don't affect how you call the classes, and some where you do have to update those calls all over your code - same problem as Aaron says is avoided. Seems to me that the main protection against this is to keep the database calls in one module in your application - with that module's API matching the logic of the application as cleanly as possible. I'm not seeing how whether that app module uses some sQL, or various abstraction classes, makes all that much difference to the work involved when schema is changed. But I'm sure it does. Can someone enlighten me? Cheers :-) -- Jamie _______________________________________________ BristolBathPM mailing list [email protected] http://mailman.bristolbath.org/mailman/listinfo/bristolbathpm
