Re: Transaction Oriented Architecture (TOA)

topmind wrote:
Thomas Gagne wrote:
<snip>
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?

If you change any DDL you're going to explore for SQL. I doubt that if SQL has leaked into the application you'll only be visiting two places. You'll visit every place SQL was affected by the DDL change--if you can find them.
<snip>
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.
I'm not concerned about single fields like SSN. I'm more concerned with a mapping of an Account class to an account table and their fields. If the account table changes or some of its lesser-used columns moved to another table then I have a maintenance problem. It matters little to me if I'm editing XML configs, Java code, or anything else. Any update that can be localized to the DB only, the happier I am--especially if I don't have to build/ship/system-test a bunch of software.

--
Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
.

Relevant Pages

  • Re: Critique of Robert C. Martins "Agile Principles, Patterns, and Practices"
    ... since all the SQL is concentrated in one place rather than spread out and duplicated. ... From my point of view it is significantly less since I can forget about the SQL and Schema while dealing with the business rules and interface. ... The partitioning of the code in the Payroll example is just that, ... There are many reasons why such a separation might be beneficial. ...
    (comp.object)
  • Re: Critique of Robert C. Martins "Agile Principles, Patterns, and Practices"
    ... wrap the SQL. ... forget about the SQL and Schema while dealing with the business rules ... The partitioning of the code in the Payroll example is just that, ... such a separation might be beneficial. ...
    (comp.object)
  • Re: Application logic and Business logic
    ... Before separation: ... bar = "glob"; ... Now suppose we have to add a new factor to the SQL. ... Find the function implementation (callee) ...
    (comp.object)
  • Re: Application logic and Business logic
    ... > Before separation: ... > Now suppose we have to add a new factor to the SQL. ... causing a doubling of the work required to address a requirements ... His assumptions of change patterns don't ...
    (comp.object)
  • Re: Transaction Oriented Architecture (TOA)
    ... 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 ... DB, when a mapping exists between the two, the nearer that mapping ...
    (comp.object)