Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Robert Martin wrote:
> The best answer is "one". We would like all the SQL to be placed in
> one module, or one group of modules that are all related. More
> importantly we want that module (or that group of modules) to be
> independent. No other modules in the system should know that it (they)
> exist(s). All dependencies point AWAY from the SQL modules.
>
> |App Modules|<------|SQL MODULE(S)|
>
> This means that the SQL modules can be modified or replaced without
> affecting the application at all.
>
> This kind of dependency management and detail isolation is the essense
> of object oriented design.

Abstraction and encapsulation can't just be waved about without thinking about their application. For example, in the above dependency, what if you need to share data among several different applications? In that case, why should the SQL modules (the data to be shared) depend on specific application modules? What if those modules are replaced?

Furthermore, I still don't know what you mean by "SQL modules." It could mean any of the following:

1. the interface to the DBMS (how raw SQL strings are sent to the DBMS)
2. all JDBC/ADO/etc. code
3. knowledge of tables and rows as the data source

It's #3 I object to. I've created mapping layers (not my idea) which allow swapping an XML "data source" for a SQL (JDBC) one. A colossal pain in the ass which is complicated by the fact that the underlying "data models" are incompatible; the XML was much more restrictive, forcing dumbing-down. I don't believe its hierarchy adds much meaningful information to flat files (having create mapping utilities from flat files to object hierarchies, I have to say that's it's not rocket science and has fewer pains in the ass than XML does, despite the availability of parsers).

Relational is more powerful than other data models, and models the business better. SQL continues to be better than XML and the others, despite its weak adherence to relational ideas; even watered-down, perverted relational is better than the alternatives. I wish my languages had relations (and its necessary components, constraints and user-defined types - aka objects) as first-class citizens - it would eliminiate a lot of unnecessary code, catch errors in my thinking, and eliminate the "impedence mismatch."

So how long do we need to cater, in all the modules of our systems, to the lowest common denominator? Objects, as a "data structure," are laborious and the volume of static methods I see in every Java system, and the number of reflective frameworks, indicates that general utility functions and generic code are preferable to the hand-rolled "data objects" / "transfer objects" / "value objects" which seem to be proferred as the O-O solution to "storage independence," a strawman response to both SQL and relational.

• Eric