Re: Mixing OO and DB
Date: Mon, 10 Mar 2008 19:47:28 -0500
Message-ID: <2008031019472897157-unclebob_at_objectmentorcom>
On 2008-03-09 15:50:07 -0500, Marshall <marshall.spight_at_gmail.com> said:
> On Mar 8, 6:14 pm, Robert Martin <uncle..._at_objectmentor.com> wrote
>
>
>> e.g. >> >> slaggards = find_slaggards(); >> fire(slaggards); >> >> Note that the query and the rule work nicely together, but are >> separate. The query could have been used with a different rule: >> >> slaggars = find_slaggards(); >> list(slaggards);
>
> Is the set of attributes you need to fire an employee the
> same as the set of attributes you need to list them? Almost
> certainly not. You can fire them with just their employee ids,
> but for a listing for a person to read, just raw ids is not
> going to be useful or informative.
Of course the most common answer is that, performance allowing, we use queries that gather the union of columns that most or all rules need. That allows us to conserve the number of query-types.
> And in fact, even if the attribute sets *do* match up, you might
> still be wasting time. Many use-cases can be handled by
> a single update, where *nothing* needs to be retrieved.
Sure. No need to fetch anything. A good ORM can handle that.
> You want to change some fields in a table, parameterized
> on values in that and another table? A lot of business logic
> comes down to that. It can be done in a single SQL
> statement, sent to the server in a single network round trip.
Sure. That SQL statement can be wrapped in a handly little function that has an evocative name.
>
> The network is a critical consideration here. Robert's Rules
> of Encapsulation do not come at any particular performance
> penalty when all the data is held in a single process, everything
> is random access, and function call overhead is approximately
> one instruction. In a networked world, in a client-server world,
> in the programming-for-the-datacenter world, Robert's Rules
> are a performance disaster. I have observed five and six orders
> of magnitude performance difference between the style of
> programming Robert advocates and just writing plain SQL.
Sure. If you make unecessary fetches, or individual queries, you deserve a 10X drop in throughput. Don't do that. That doesn't mean you can't wrap your SQLs statements in nice functions.
-- Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 |Received on Tue Mar 11 2008 - 01:47:28 CET