Re: The wisdom of the object mentors

From: <>
Date: 29 Jun 2006 08:01:46 -0700
Message-ID: <>

> See it as the total problem description of what the developer has to
> write. With persistence taken care of, the total problem description
> then thus doesn't include how to obtain which data, that's a given.
> Without persistence taken care of, it's part of the problem
> description, and the developer THUS has to spend time on that as well.
> HOW the developer solves it, is not relevant in this.

The RDBMS takes care of persistence. The application programmer has no idea when or where the data is written to disk.

> > > it also takes more work to get things
> > > saved again.
> >
> > update boardmember set col1=? where boardmemberid=?
> > update employee set col2=? where employeeid=?
> >
> > If you show your code, we can estimate if it takes "more work" or not.
> myBoardmember.Col1 = value1;
> myBoardmember.Col2 = value2;
> myAdapter.SaveEntity(myBoardmember);

Maybe you can provide the implementation of SaveEntity too? My code snip is complete, yours is not.

> If I want to insert a new department, manager of the department and a
> new boardmember working in the department as well as a new companycar
> for that boardmember, I can do that still with the same statement:
> myAdapter.SaveEntity(myBoardmember);

Maybe, but how does the implementation of SaveEntity looks like. I can make a SaveBoardmember function wrapping the update statements too, if it makes you feel better.

> You on the other hand have to make sure the
> queries are all executed in the right order on the correct tables with
> the correct values.

Yes, statements has to be executed in corrent order with correct data, what is the problem?

> That's significant more code, in whatever language you want to use,
> which thus can lead to more bugs.

My solution has two lines of code, yours has three lines, and still you didn't provide the implementation of SaveEntity. Where is the significant more code?

> THat's also what I meant earlier in my post: if the persistence is
> part of the problem description,

If you use a RDBMS it is not. Persistence is hidden. Why is it so hard for OO guys to understand what persistence is only one feature in the bottom of the RDBMS stack? Sometimes you might use a RDBMS without persisting anything at all.

> the developer has to spend time on
> this, write code for this, and thus runs the risk of introducing bugs,

That is why you should use a RBDMS. Someone else already did it for you.

> low-level set of updates/inserts

Update and insert statements are much more high-level than any OO 3GL code.

> on a variety of tables

What is the difference of using a variety of tables instead of a variety of classes?

> which apparently belong to an entity you CAN'T USE as THE
> entity, you HAVE TO use fragments of the entity to be able to
> update/insert.

A table is normally a entity. If you need multiple tables, you probably have multiple entities. Anyway this was the situation in your boardmember example.

> (sort the DAG with topology sort, create 2 queues, one for insert, one
> for update, first run the insert queue, then the update queue, and sync
> fk's with pk's if pk side is succesfully saved).

I have no idea of what you are talking about here. What is the purpose with the queues and why do you need synchronization?

> It was more a question
> to illustrate that a problem arises if you WANT TO work with an entity
> 'Boardmember' but HAVE TO work with elements from a lower level of
> abstraction, namely the 3 tables.

But your boardmember is also a mananger and an employee. There are 3 tables and 3 classes. The tables is not more low-level in any way.

> > > Again requires FK constraint metadata knowledge,
> >
> > If you don't have this knowledge, you are not the right person for the
> > job.
> Well, I do agree with you that if you want to use a relational model
> to its fullest in software not implemented inside the RDBMS, you've to
> know the schema, but more in the way of "which entity is related to
> which entity and by what relationship type?" for example. Though should
> it be necessary through which FK fields an entity is related to another
> entity? Or should it be enought THAT an entity is related to another
> entity?

You have to know what columns and foreign keys you are using. It isn't that hard.

> > > if you update the name and some field in boardmember (like s/he
> > > gets a new companycar) you've to update two tables while you worked
> > > on 1 entity.
> >
> > Doesn't the name attribute belong to the employee entity? What is the
> > bid deal with two updates?
> You work with the boardmember entity, so you want to change values of
> that entity, not of the elements on a lower abstraction level.

Are managers and employees lower abstraction leven than boardmember? Are you talking about the level in the organization here?

> So if
> you work with a boardmember, it comes down to 1 update statement (as
> you work with 1 entity) and if you have to work with the lower level
> elements it comes down to 2+ update statements, which mitigates the
> whole purpose of having entities on a higher abstraction level.

Somewhere in your code you need all 3 update statements anyhow. Why not making a function SaveBoardmember if you feel that 3 update statements are such a big problem?

> > > > > It comes
> > > > > down to writing code which consumes entities on the level of how
> > > > > they exist in NIAM/ORM (Halpin/Nijssen, not
> > > > > on the level of an E/R model.
> > > >
> > > > Why do you need the NIAM/ORM model? If you use a RDBMS you already
> > > > have the E/R model. Adding an extra model needs some strong
> > > > motivation, otherwise it will just cause a code bloat.
> > >
> > > it has nothing to do with code,
> >
> > Read above: "it comes down to writing code..." and "it has nothing to
> > do with code". Please make up your mind.
> you referred to extra code, I refered to code consuming what's there
> on the abstraction level of a NIAM model. So in my case I don't need
> extra code, in your case you think you need extra code.

I don't really understand what you are talking about here. I have shown my code, you have shown yours. My code has fewer lines of code than yours. Prove me to be wrong if you don't agree.

> my point was that if you work with
> an entity on the abstraction level of a NIAM model, why do I have to
> work with low level elements which reside on a lower abstraction level?
> That mitigates the whole abstraction level on top of the E/R model.

I don't work with the E/R model nor the NIAM model. I work with the relational model using SQL. My entities are: boardmember, employee, manager. You have the same same entities. I can't find any difference in the level of abstractation here.

Fredrik Bertilsson Received on Thu Jun 29 2006 - 17:01:46 CEST

Original text of this message