Re: Transaction Oriented Architecture (TOA)

Responding to Gagne...

I hit the wrong keyboard combination and my original reply disappeared. It hasn't appeared on the newsgroup yet, so I assume it went to the Great Bit Dump in the Sky. If it does show up it might be amusing to compare the answers.

In the article I propose the impedance mismatch between Object Oriented Languages can Relational Databases can be easily eliminated. All we have to do (as OO programmers and designers) is stop pretending the database doesn't exist.


I don't think the issue is ignoring the database; it is recognizing that the database is a different subject matter applying different business rules than the problem solution. Enter stage left, dancing: separation of concerns and decoupling through subsystem encapsulation.

There is nothing to prevent abstracting the database subject matter in a classic OO manner with objects like Schema, Table, Tuple, and Query. One can provide behaviors to deal with database-specific mechanics like the construction of SQL strings. One can easily provide optimizations tailored to the database paradigm de jour. One just has to realize that problem one is solving in accessing a database is different than the problem the application is solving for the customer (at least outside the CRUD/USER arena).

But that abstraction is exactly the busywork I think that can most-often be avoided. Admittedly, in our own application (and other's I've been a party to) we have abstracted tuples--but only as a mechanism for making an RDB's answer (projection) easily accessible by making its manipulation idiomatic to the programming language. For example, using structures in C or instances in Smalltalk.

The basic problem is that the RDB paradigm is designed for generic, ad hoc access of data. IOW, it is optimized to be independent of what problem is being solved with the data. Once one is outside the CRUD/USER arena, applications are optimized to solve very specific problems. That optimization involves different approaches to things like relationship navigation (e.g., object-level instantiation vs. table-level). So the views of the data should be /expected/ to be different. Therefore one solves the business problem first and then worries about how one maps that solution view into the DB view.

In addition, a big advantage of encapsulating in a subsystem is large scale reuse. Once one abstracts the invariants of the DB paradigm de jour properly, then the subsystem can be reused across applications. Thus the RDB paradigm is abstracted exactly the same way regardless of the semantics of the data. That is, one encodes the invariants of the paradigm and leaves the details to data (e.g., mapping of table names, field names, etc.). To do that one just applies basic problem space abstraction to the RDB subject matter, so there it really costs very little extra to achieve that reuse.

However, for that to work...

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 and emphasizing low coupling between modules. It just didn't say specifically that one needs to encapsulate database access in a subsystem behind an interface to do that. B-)

It did quit a little early (more is planned--specifically what it looks like in code) but the primary abstractions it will propose have to do with making procedure calls idiomatic and explicit rather than abstracted and implicit (hidden). I'm of the opinion that the more obvious the database (or at least its interface) is the more easily maintainable an application becomes. I've nothing against creating frameworks and patterns to facilitate those programming activities, but prefer the concept of a problem domain transaction to language-specific expressions mapping 1:1 (or some other low-ratio) with anything physically present in the database (like tables, views, or the columns in each). From this perspective, the only mapping TOA endorses is between a procedure's answer and the language's idiomatic expression of it.

One needs to design the interface to the problem solution's needs. Thus it is the interface that needs to be replaced during large scale reuse (think: Facade pattern). To be successful the interface needs to be a pure message-based interface so that each side can map the message ID and data packet into its own unique view. That, in turn, means a consistent mapping of identity on each side of the interface.

Fortunately, that is usually easy for data, especially for paradigms like the RDM that are designed to provide generic identity. Half the work is done if the DBMS schema is available to the application. So one just needs a bunch of table lookups to map data packet elements into Table/Field identifiers to construct SQL strings. Those lookup tables get defined from external configuration data that maps the interface messages into the RDB schema.

The price of this is encode/decode of message data packets on each side of the interface. For a SQL RDB, that effectively means duplicated dataset encode/decode. Fortunately DB access is in milliseconds while encoding/decoding data packets is in microseconds so nobody is likely to notice anything except the developer's extra keystrokes, which don't count in the overall scheme of things.

When there actually is a 1:1 mapping between the solution and DB views, that message indirection is redundant. But that decoupling pays huge bonuses when the mapping is not 1:1, when the mapping changes in the future, and for large scale reuse across applications. The thing is that once one is outside the CRUD/USER realm when solving some customer problem, one can't know when the mapping will be 1:1 or when it might change.

So one should solve the customer problem without worrying about what the DB looks like. If some objects happen to map 1:1 that is transparent because the interface is designed to the solution's data needs (e.g., "Save this pile of data I call 'X' and give it back to me when I ask for 'X' later"). IOW, one should be able to solve the customer problem and design the DB access interface without knowing or caring how the stored data is ultimately organized.

At another level, I don't see how you can advise not embedding SQL in the problem solution without providing the indirection of a message-based interface. Creating surrogate objects for the RDB that do construct SQL queries and letting other objects talk to them to do the grunt work doesn't really reduce the maintenance risk very much. When the schema changes you are still touching the solution subject matter's code and that implies risk of breaking the solution over a pure DB issue.

It will also be tempting to bend the solution around those surrogates, which can lead to a less optimal and maintainable solution. That is, if one has a preconceived notion of what the data looks like, one will be tempted to build the solution around that view. So the generic, ad hoc tail is wagging the solution dog.

IOW, I think maintainability will be maximized when the subject matter concerns are clearly decoupled. The strongest way to do that is by encapsulating the DB access in a subsystem behind a pure message-based interface.



*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Beginning C# Q
    ... starting out with a network app0lication, you have an awful lot to swallow. ... Designing your database is therefore, not quite the first step, particularly ... Groups table, which defines which Groups users belong to, and a Permissions ... That is why an Interface is called an Interface. ...
    (microsoft.public.dotnet.framework)
  • Re: Transaction Oriented Architecture (TOA)
    ... If one builds the application around the database view, ... The problem solution should not have to know about mechanisms like SQL query construction, optimizations like anticipatory caches, or encoding/decoding of dataset formats. ... Note that the CRUD/USER environments already provide exactly that encapsulation by providing a Data Layer that is isolated from the rest of the application through an interface. ... TOA/TOP proposes the database and its application domain stored procedures are the only persistence mechanism necessary, and that the benefits of a focused, single, data-permeable gateway between application and database far exceed the benefits of O/R mappings--regardless of abstraction--and that its lightweight appearance shouldn't be dismissed as missing heavyweight kick. ...
    (comp.object)
  • Re: OOP style
    ... Component classes have all their main logic in a Custom base class ... database access unit if they didn't already start with a full DB layer; ... My latest application started with an extensively designed object model ... Typing in the implementation of the database interface is ...
    (comp.lang.pascal.delphi.misc)
  • Re: OOP/OOD Philosophy
    ... You appear to assume that, in order to isolate the database from the gui, ... the GUI layer uses a specific interface of the business ... This is where you need to place logic against the data structure that ...
    (comp.object)
  • Re: implementing roles in OOP......
    ... everything should be driven by abstracting the problem ... my draft interfaces define what sort of thing I would ... All I need is the Composite relationships to navigate, ... IEnumerator is an interface defined by my environment, we can put, ...
    (comp.object)