Re: Transaction Oriented Architecture (TOA)


Matt McGill wrote:
but does not
appear to advocate wrapping SQL in OO constructs, or even using any OO
constructs at all. What the article /does/ suggest is the use of a set
of stored procedures to act as an API for application programmers
writing code against the database.

This is still "wrapping". Whether that is an "OO design principle"
depends on who you ask. Perhaps this is a disagreement over semantics.
OOP/OOA/OOD is not defined very consistently. However, it appears to
be a general "OOP habit" to wrap anything that is not OOP behind
classes, or perhaps stored procedures as a consolation.

With a well-defined API in place,
you can change the applications and the database independently of one
another as long as the API stays the same.

Yes, but it is not a free lunch, as already described. I weigh the
maintenance trade-offs based on past experience, and often decide that
stored procedures (or wrapping SQL in general) is not warrented per
case or per app.

What maintenance trade-offs? The only trade-off that seems to apply
here is time vs. flexibility. Introducing stored procedures gives you
more flexibility,

Prove it with code scenarios.

and adds the time overhead of actually creating the
stored procedure.

Bull. Suppose you need to add a new field to a report. If the SQL is
in the report module, you only have to visit the one report module: a
single file/unit. If the SQL is in an SP or SQL-central area, then you
have to visit 2 places: the app module ANNNNDDD the "SQL place", not
one.

2 > 1

Similar applies to inspecting the SQL related to a module. I don't like
having to jump around to find corresponding SQL for a task. It wastes
time. It is red-tape busy-work.

Except that I'm not convinced there's any time
overhead for anything more complicated than an isolated select, insert,
or update. A database transaction (not a transaction as described in
the article being discussed) often involves multiple selects and
inserts/updates, with various sanity checks mixed in. Not all
programming languages make DB access easy,

Then dump F-ing Java. "SQL is difficult to use with stupid languages"
is actually something I might agree with.

and not all DB apis allow
you to make use of all the vendor-specific functionality present in any
given database product.

Please clarify. If the app is only passing the SQL string onto the DB
as-is, when how can it "read" the SQL and stop stuff it does not like?
AI?

The time you'd waste writing DB access code in
C will more than account for the time it takes to define a stored
procedure, and once you have the procedure, calling it from your
language of choice is simple.

C sucks too. People use it for execution speed, not because it is
convenient for developers. It is sometimes called "the new assembler".

Experienced developers weigh the trade-offs, not stick to rigid dogma
that X must *always* have Y, etc. (Some call me dogmatic against OOP,
but it is just that OO being the best solution is too small a
percentage of most apps to bother introducing yet another paradigm into
an app, complicating staffing issues.)


That sounds like a solid approach to me by itself. The article does go
farther than that of course, leveraging the stored procedures to
implement detailed auditing within the database. But I don't understand
your objection to keeping an audit history in database tables either.

Where did I object to that?

Here:
Additionally, there's no transaction history on SELECT statements
(unless you wanted to enable security auditing.. but that's nasty).

Are you saying that your DBMS cannot log view-based query access? If
so, that is a flaw/shortcomming of the DB product, not of relational in
general. Some OO'ers suggest they like OO because even though one ends
up reinventing a lot of DB-like features in OO app code, at least they
have control over it such that they can add missing features. But that
is almost like saying one should write their own word-processor because
MS-Word has bugs. There are open-source RDBMS such as PostGre that
permit one to alter the source code if needed, if you want to go that
route.

You are shadow boxing. The OP's need for logging has nothing to do with
OO, and OO techniques were not proposed as the solution. The RDBMS
likely can log query access, but who's to say that the logs it produces
are easily manipulatable programmatically?

Example? I find it a lot easier to manipulate logs in a DB or tables
than in arrays, etc., (Assuming proper normalization.) especially with
table-friendly tools/languages.

Modifying the source code of
an RDBMS to add functionality that can be easily obtained via stored
procedures is ridiculous, and casts a dubious light on all of your
conclusions regarding 'maintenance trade-offs.' I can think of few
maintenance nightmares quite like maintaining your own special branch
of Postgres for a few app-specific requirements. That's a way to get
yourself fired.

The Postgres suggestion is only one of several suggestions. You word it
as if it is the only approach I suggested. Some shops roll their own
OODMBS of sorts. Why is Postgres worse than such a sin?

Overall, you have not offered enough specifics for me to see what
actual alternatives are available. If all you have are un-inspectable
anecdotes, those are a dime a dozen and point both ways, and are thus
nearly useless here.

And again, where did I object to "keeping an audit history in database
tables"?


-Matt McGill

-T-

.

Relevant Pages

  • Re: Just say no to threads [Was: Software architecture]
    ... they knew there was going to be a database in the app. ... Now my colleague just spent a couple/three weeks designing an SQL ... Turns out they have a flat file of sample information, ...
    (comp.object)
  • Re: SQL Access security from Window Application
    ... you could have your app handle authentication by emulating the ... Currently my application access the SQL using ... >System.Data.SqlClient and all forms use stored procedures. ... >passwords in a protected file but this creates a problem on remote systems ...
    (microsoft.public.dotnet.general)
  • Re: Question about forms and data storage
    ... app that synchs the data from SQL to a list, ... or look at moving the core data into the sharepoint ... list over the database... ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Transaction Oriented Architecture (TOA)
    ... OOP is not required to wrap SQL. ... of stored procedures to act as an API for application programmers ... writing code against the database. ... With a well-defined API in place, ...
    (comp.object)
  • Re: Get all stored procedures
    ... For SQLSERVER, we can use the following SQL statement to query the SP ... objects of a certain database: ... Microsoft Online Support ... | Thread-Topic: Get all stored procedures ...
    (microsoft.public.dotnet.framework.adonet)