Re: What databases have taught me

frebe73_at_gmail.com wrote:

> > > That's my point, most OO people claim that the query result
> > > should be mapped to a "domain objects".
> >
> > Correction: Most 'OO people' (whatever that means) who think
> > Domain Driven Design (DDD) is key to success. I'm not one of them
> > btw, and I'm sure a lot of others who happen to use an OOPL to
> > write their software with also think DDD is overdoing things.
>
> So you agree that making classes like customer, employee, product is a
> bad idea?

        No, I find sticking every little method which consumes customer data into the customer entity class a bad idea. For example: a check to see if the CustomerID value set is > 0 can be located perfectly inside the Customer class. However the check if a customer is a gold customer, i.e. a customer who has placed n orders in the last m months, touches orders as well. If you place that inside the customer class, you then have to know how to obtain order data. It's my opinion that multi-entity consuming logic is better off outside an entity class (and I also think my gold-customer example is not that good in this case, but it's early in the morning ;))

        If you are developing your software in a procedural non-OOPL environment, having a customer object/struct is not really natural. The same thing goes for an OOPL environment where untyped table-rows are unnatural: everything else are typed objects after all.

> > > > The first stage of decoupling your SQL statement might be:
> > > >
> > > > RowSet findAllEmployeesOlderThanLivingIn(age, city) {
> > > > return execute_sql(
> > > > "select name from employees where today()-date_of_birth > ?
> > > > and city = ?", age, city);
> > > > }
> > >
> > > Many OO evangelists (including yourself) would argue against this
> > > solution, because the caller of findAllEmployeesOlderThanLivingIn
> > > need to know about database column names.
> >
> > Gee, another label. Putting labels onto people isn't going to make
> > your own arguments look any stronger, only weaker.
>
> I don't know how many times I have seen people at comp.object refusing
> to use any solution that doesn't hide database column names.

        that doesn't mean everyone from c.o thinks the same, like not everyone in c.d.t. thinks the same about databases (otherwise there wouldn't be any discussion ;))

> > In the 'OO world'
> > there is also a lot of diversity among how people see the
> > techniques at hand:
>
> That makes it very hard to claim advantages of OO, doesn't it? If
> someone claims that "OO makes change management easier", he has a
> problem supporting that claim, because he first has to publish his
> definition of "OO".

        No, it's about the ideas behind OOAD, not the practical aspects of a subset of these ideas in an OOPL's featureset.

> > some see it as a way of life and pollute the world with
> > zealottery and advocacy no-one but themselves benefits from and
> > others see it as a tool to get the job done. In the 'RM world' it's
> > the same thing.
>
> The difference between the relational model and the OO model is that
> the relational model has a formal definition.

        you're talking about apples and oranges. it's great that the relational model has a formal definition, but a DBA using mysql will have to work hard to get it working in practise. The "OO model" might not have a mathematical based definition, that doesn't mean it's therefore something not usable. The procedural model also doesn't have a formal definition, so you would argue it's also not usable?

                FB

-- 
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#) 
------------------------------------------------------------------------