Re: Transaction Oriented Architecture (TOA)


Thomas Gagne wrote:
topmind wrote:
H. S. Lahman wrote:

Responding to Gagne...



It seems to me the article was most of the way there when it proposes
things like isolating SQL so it is not embedded in the problem solution



I have to disagree with such advice. Isolating SQL is oversold. One
does not swap database vendors often enough to make it worthwhile.
Maybe if you sell a product that is designed to be used by multiple
DB's, such makes sense; but not for most custom apps. It creates more
work and more red-tape. (We have spent gazillion messages on this topic
before.)

Eliminating SQL in the application in TOA/TOP isn't about database
vendor independence, its about good design and maintainability.

In that case then SQL separation is "bad" because it often forces you
to visit 2 different places to make changes: the app code and the SQL
area. If they are together in the same module, then you don't have to
do the Separation Texas Two Step. No hopping around = saved time.

What is the alleged bad scenario that separation protects us from?



and emphasizing low coupling between modules.


I've found "coupling" to be a rather subjective property such that it
is a nearly useless catch-phrase these days. (That is until the point
somebody defines it clearly and not tied to subjective criteria, such
as what app part is more likely to change.)

Coupling is a relative term, not subjective--similar to a noise ratio.
Coupling describes the interdependence between two related objects. Low
coupling is realized when significant changes can be made to one object
without affecting the other. High coupling indicates changes can not be
made to one without requiring changes to another.


Okay, but often there are multiple "axises" by which something can
change and not all changes are necessarily an equal frequency. It
usually turns into a case of balancing and weighing alternatives, not a
slam-dunk single right choice. OO fans have a distorted view of change
probabilities in my observation, driven by books that keep pointing out
change patterns that OO is good at, ignoring those it is bad at.


In the case of OO and
DB, when a mapping exists between the two, the nearer that mapping
approaches 1:1 the more tightly coupled the application and DB are. In
a 1:1 mapping nothing in the DB can be changed without affecting the
application, nor can anything be changed in the application data model
without affecting change in the DB.

Can you present a specific scenario? If you don't meta-tize the
elements (such as in a data or field dictionary table, or the ugly fad
of XML configs), then such would often be needed if one is dealing with
the same thing. If the Social Security Number (SSN) is stored in the
database, but the app also uses the SSN, then there is likely to be an
unavoidable coupling there.


--

-T-

.