Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

In article <LUKfg.16278$A26.376787_at_ursa-nb00s0.nbnet.nb.ca>, Bob Badour <bbadour_at_pei.sympatico.ca> wrote:
>Christian Brunschen wrote:
>
>> LDAP is not usually considered 'obsolete'. For its specific purpose it
>> appears to be fairly well-liked and in widespread use.
>
>I agree that obsolete is a very poor choice of word. It implies
>unpopularity of something that might still be in good working order. In
>this case, the thing is very popular while not necessarily working all
>that well.

In my (admittedly limited) experience, LDAP seems to be rather successful and working fairly well for its intended purpose.

>> The interface should indeed be between the application and a pluggable
>> service - but the database can be exactly such a pluggable service. SQL
>> itself is a shared, well-defined common interface that permits using many
>> different vendors' database implementationas as pluggable services.
>>
>> In the case of authenticating a user, when using LDAP as a back-end there
>> might be a pre-existing 'authenticate this user in this LDAP database'
>> operation available, which could be used to almost directly implement out
>> 'wrapped' user authentication service; when using a SQL RDBMS as the
>> back-end, we might store a one-way-encrypted version of the password in a
>> column of the user table, and perform authentication with a 'select name,
>> password from user where name = foo and encrypted_password = xh54k' query.
>
>Or one might simply use the very powerful and transparent authentication
>and security features of the dbms itself. I see no reason to fantasize
>additional complexity.

Not every RDBMS has 'very powerful and transparent authentication and security features'.

However, if it is known that one will be using a specific RDBMS that does have them, then yes, one could indeed use those. But since different RDBMS:es may offer these services through different interfaces, it would still make sense to place any such code in pluggable modules, so that the application would be using a single, shared interface, that would be implemented as necessary for each possible user authentication service, whether using LDAP, ORACLE, flat files, or something else.

>>>There might be other examples there some data by techical reasons need
>>>to be stored somewhere else but a SQL database, but that is still not
>>>an argument for separating all SQL statements by default.
>>
>> The reason for separating SQL statements from the application code is the
>> same reason as for generally writing functions/procedures/methods.
>
>But I fail to see how abstractions separate anything from the
>application. The definitions of the functions/procedures/methods remain
>part of the application.

If you have any part of any system that may need to vary, then having a well-defined interface to that part of the system, and having all interaction with that part go through that interface, is just a generayy good idea. And using a higher level of abstraction means that you are hiding unnecessary implementation details, which is also usually considered a good thing.

>> ... basically putting an SQL front-end on an LDAP database, in order to
>> be able to use SQL as a common database interface? That's certainly one
>> solution. My preferred solution is to define a higher-level interface that
>> is then implemented using whatever each database's most appropriate
>> interface is.
>
>How does one create a higher-level interface in a lower-level language?

People build higher-level abstractions on top of lover-level ones all the time. I fail to see what problem you are having?

>Do you likewise recommend implementing higher-level interfaces to your
>C/C++/Java/OO-du-jour in assembler?

I advocate using the proper tools for the job, using the most appropriate level of abstraction, keeping separate parts of the system separate (and potentially pluggable).

If you're writing an embedded application in assembly language, but you have available to you a library that is written in a higher-level language, then you may well end up implementing something that uses higher-level abstractions than in either assembly language or the procedureal or object-oriented or otherwise higher-level language that the library is written in.

> The end result is essentially the same: There's a sihgle,
>> well-defined interface through which we can work with the data as
>> necessary from the point of view of the application.
>
>What makes it well-defined?

the process of designing it well, which includes looking at the requrements that the different parts of the system have on each other, and putting together interfaces that expose the necessary functionality, but without intermingling the details that don't need to be shared, thus decoupling the implementations from one another.

>The relational model is well-defined
>equivalently as set algebra and predicate logic. What causes you to
>consider an ad-hoc collection of features for creating large complex
>state machines well-defined?

When an interface is clearly, succinctly and precisely defined, as well as offering the necessary functionality in a useful and usable manner, without leaking implementation details unnecessarily.

>>>(I have done a similar solution while converting stored
>>>procedures to Java. The client still thinks it is calling a stored
>>>procedure in the database using "execute procedure abc()". But the ODBC
>>>realized that this is not a database call and calls the appropiate java
>>>method instead.)
>>
>> Cool. One could consider what you are doing as basically implementing an
>> RDBMS with an SQL interface, which just happens to delegate a lot of its
>> functionality to a second, pre-existing RDBMS with an SQL interface; not
>> entirely unlike using the Facade design pattern.
>
>So, I take it you consider expending considerable effort to re-invent
>existing services "cool" ?

Not in itself, no. Had I written "Way cool, man!" then perhaps that inference would be warranted, but I didn't. I meant 'cool' in the colloquial sense of 'OK', or in this specific case, 'I'm glad you managed to solve your problem in a way that worked for you'.

Incidentally, the fact that you had to perform this 'interception' suggests that the interface that the client used didn't sufficiently insulate the client from changes to the service it was using. Had a higher-level interface been used instead, then the first implementation (which would have called the stored procedures) could have been replaced straightforwardly by the second implementation (which implemented that functionality in Java), but without having to 'intercept' the 'execute procedure abc()' calls.

>Does "cool" justify the expense? Are you the
>one actually paying for "cool" or is that someone else?

I don't aim for 'cool' solutions. I aim to solve problems, and to have toe solutions to those problems work well. Sometimes, as a side effect, those solutions can be 'cool', sometimes even 'elegant' (and 'elegant' is something I do strive for, unless it conflicts with other more important goals).

Why do you focus so on that single word?

Best wishes,

// Christian Brunschen Received on Fri Jun 02 2006 - 12:21:59 CEST