Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Sat, 17 Jun 2006 13:00:48 GMT
"topmind" <topmind_at_technologist.com> wrote in message
> To be fair, I think R. Martin tends to focus on industries where
> reliability and testability are more important than being nimble. Extra
> layers for e-beurocracy between the DB and app code perhaps make it
> easier to test stuff in isolatable pieces perhaps and have like a
> sign-off sheet and official tests for each part.
> Most companies do not want to spend the money on such stuff and thus
> are happy with thin layers betweens between the app and the DB.
> Further, it may make most changes easier since there is less middle-man
> code between the DB and app to also change.
> I cannot be sure this is what R. Martin focuses on, but the nature of
> his writing implies such. I can see the need for more formal separation
> in say the medical industry where companies can get sued for hundreds
> of millions if a device goes wrong and they need to hunt down the
> organization or person involved to punish and sue, like we love to do
> as a nation.
I've been following this debate, and I have a slightly different take on what R. Martin is talking about.
Most of R. Martin's recent posts in this discussion have been directed to the *internal* structure of the application. The whole question of whether it's better to sprinkle SQL all over the place in the application, or collect it one module, is moot if your point of view is external to the application. That's my point of view.
Don't get me wrong. The point is worth discussing. But it's only worth discussing in the context of individual application design, development, and maintenance.
If you look at things from a coarser level of granularity, the DB and the DBMS that serves it up are both replaceable parts. You'd like to be able to swap it out, and swap in a new one without the "ripple efect" swamping all the existing applications in a huge maintenance effort.
But (and this is a big but) from this level of granularity, each application in the collection is *also* a replaceable part. You'd like to be able to swap out any application, and replace it with a new one that provides data to the DB without having the "ripple effect" propagate to all the other applications that use the same DB.
Modularity and encapsulation help control the ripple effect within an application. Within a collection of applications that all treat the same DB as a data nexus, data independence is the best way to control the ripple effect.
The problem with application developers is that they tend to fall into the trap that says that their application is the center of the universe. The problem with database designers and DBAs is that we tend to fall into the opposite trap. We tend to think of our database as the center of the universe.
I suspect that there is a third trap, one that network people tend to fall into. But I don't have enough experience to describe it.
Strategic data planners need to avoid all three traps. Received on Sat Jun 17 2006 - 15:00:48 CEST