Re: Relational-to-OOP Tax




Kreeg wrote:
topmind wrote:
Kreeg wrote:
frebe wrote:
I have to disagree, there. Now, I realize that your specific beef is
with CRUD apps and OO, and I have to agree that there are times --
especially with simple CRUD apps -- that object-relational mapping is
overkill. I also think that ORM does have its place.
O/R mapping is a bad idea also in non-CRUD applications. You are
hiding predicate logic and set theory behind a network graph. You
loose a lot of flexibility.
However, to say that using arrays/resultsets/datasets in OO "isn't
really OO" is not true IMO. Object-relational mapping isn't the "one
true OO", and implicating it as such in this context is just building up
a strawman for you to attack.
Please read the previous posts in this thread. There are a lot of
claims that SQL need to be hidden in a separate layer and that the
result should be converted from resultsets to objects. You might not
agree, but this seem to be the common opinion at comp.object.
Hiding the sql is different from storing data in-memory as resultsets.
You can hide the sql through stored procs (or heck even a view if that's
your preference, which it likely is) and still have the application use
resultsets/datasets.
Most "OO" people argue that the database schema should be hidden. That
is why they can't allow SQL statements in the "business layer". If you
use resultsets in the "business layer", this layer is aware of the
schema. Obviously I don't agree with this hiding thing, but that seem
to be a common opinion.

Right, and what I'm saying is that the use of resultsets is independent
from hiding the schema or hiding the sql.

For example, a resultset that contains 'FirstName', 'LastName',
'PrimaryAddress' and 'MobilePhoneNumber' and an object that contains
four properties by those same names still hide the actual database
schema, in which addresses and phone numbers are stored in child tables
to the customer table.

You remap them? That is a waste of code if they are pretty close to
what you remap them to. If not, then you are only using objects as
glorified associative arrays.


Not sure what you mean by 'remap'. What is a waste of code? The hiding
of the sql through a proc?

firstName ==> x.first_name
ssn ==> x.soc_sec_num
hourlyRate ==> x.payRate
etc...

If you do what R. Martin suggests, you almost have to do remapping
because you wouldn't necessarily know what the schema or query is yet.
If you treat the schema or query as a first-class item, then you can
have an associative array contain the results and just use the columns
instead of have code to explicitly remap schema names to "internal"
names. It is automatic, saving code and mapping effort. (If you don't
like a name, you can usually use the query to supply an alias, such as
an AS clause.) Similar things apply to saving it back if needed.

-T-

.