Re: What databases have taught me
Date: 04 Jul 2006 08:50:25 GMT
Message-Id: <xn0eobmfg4syt4004_at_news.xs4all.nl>
frebe73_at_gmail.com wrote:
> > > Using a decoupled approach I have to do this
> > >
> > > findAllEmployeesOlderThanLivingIn(age, city);
> > >
> > > [Interface definition]
> > > findAllEmployeesOlderThanLivingIn(age, city);
> > >
> > > [Implementation]
> > > findAllEmployeesOlderThanLivingIn(age, city)
> > > {
> > > select name, and all other columns
> > > from employees where today()-date_of_birth > ? and city = ?
> > > result = new Array();
> > > foreach (row) {
> > > emp = new Employee(row.name, row.aaa, row.bbb, ....);
> > > result.add(emp);
> > > }
> > > return emp;
> > > }
> >
> > The two stretches of code don't do the same thing. the first simply
> > returns the employee name. The second tries to build an employee
> > object.
> > 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 DomainDriven 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.
There's also a big difference between:
a) creating classes which represent entity definitions at the NIAM/ORM
level and which allow you to work with entity instances (== data) more
easily in an OOPL environment
and
b) The domain classes required for DDD.
b) has the disadvantage that if you want to show a list of order entities with the companyname of the associated customer entity in 1 list, you have a problem unless you map another domain object onto the relation created with the query.
> > 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 makeyour own arguments look any stronger, only weaker. In the 'OO world' there is also a lot of diversity among how people see the techniques at hand: 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.
> > I think you'd need this code anyway if the above query was issued
> > from more than one place. I doubt you'd want to duplicate the
> > string.
> > If I need to call exactly the same query from more than one place in > the application, obviously I would create a function (like I would do > anytime the same fragment of code is written multiple times). But the > probability of this query being called from more than one point is > rather low, don't you think so? The query is tailored for the problem > in hand, and you should only make the same implementation once. > Otherwise you have duplication on a higher level. It's not always the right thing to do to make it 1 function. Thereason is that if you place the query in one place and call it from, say, two spots, it then makes these two spots dependent on the function's functionality, which thus means that if you need to alter the query for one spot, you thus have to realize it will affect more spots. This then thus would require you to create a new function for the changed behavior, which could in the end lead to a lot of functions of which the dependencies are unclear, unless you have tools which show you call graphs. I.o.w.: if you have dependencies on behavior, it's often a source for more maintenance.
> > > A very typical scenario is the save method in a DAO. In OO, one
so it's a problem, correct? unless it's an NP, you can find a
reasonable solution for it. Engineer that solution into your program.
With meta-data, a simple SQL generator and the data at runtime it's
easy to produce the query text you need without having to write a lot
of code.
> > > normally write one save method with one update statement,
> > > updating all columns regardless they should be updated or not.
> >
> > If that's a problem, then don't do that. Update only those columns
> > that have changed. One would use a special method in the
> > EmployeeGateway for that purpose.
>
> This will give me a lot of update statements that are only used once.
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#) ------------------------------------------------------------------------Received on Tue Jul 04 2006 - 10:50:25 CEST