Brian Bray wrote:
>
>
> The real difference is the point of view of the modelers. Using Corba
> just to "wrap" SQL tables is throwing away it's major benefits.
>
I agree with this point, so called wrapping is usually reserved for
legacy interfaces that cannot natively support objects.
>
> Using
> SQL to implement Corba objects is a common design approach, but the data
> storage mechanism becomes just an implementation decision.
>
This statement is not restricted to CORBA, it is true of any object
design/implementation. I rather think a fundamental design decision is
whether to use full object principles in the design. I also rather
think this is related to the distinction that was made earlier as to the
two types of folks on this list: researchers and practitioners.
Researchers may very well be versed in object approaches (you really
have to have done an object project to understand it, I fear), while
practitioners are not and have found the simplicity of the SQL model and
tools directly useful.
For example, putting on my object hat, I will elaborate Brian's comment
above. I wonder if it makes sense to very many of you?
Creating objects which contain data with behavior, perhaps focusing on
objects to represent the various process's and events in primary care,
might be the initial design target. Those objects then become the
design atoms, so to speak. At this point, mapping of those objects into
various persistent storage technologies, SQL databases, among them,
becomes an implementation issue as Brian has suggested. By saying that,
I mean that the logical thinking and bulk of programming done in the
system are on the object atoms and not at the SQL level at all! There
is very great power in this conception, but it does tradeoff a layer of
abstraction today for simplicity tomorrow( i.e. native object storage is
not common today, so a wrapping layer to SQL is needed).
S/MIME Cryptographic Signature
