Re: Mixing OO and DB

From: rpost <rpost_at_pcwin518.campus.tue.nl>
Date: Sat, 08 Mar 2008 11:51:12 +0100
Message-ID: <74072$47d26fa0$839b4533$30059_at_news1.tudelft.nl>


Robert Martin wrote:

>>>> get_accountant("Bob");
>>>> or
>>>> find_by_name_and_department("Bob", "Accounting");
>>>
>>>> I'm sure you can think of some others that would read nicer than the SQL.
>>>
>>> Now throw another column into the mix. How many methods are you
>>> going to end up with? What will you have gained?

[...]

>Two points.
>
>1. We don't need a class for each, we need a method for each.
>2. We never need more methods than SQL statements.
>
>So unless you have 1024 SQL statements in your application code, you
>aren't going to need 1024 methods.

The real point is that these methods are essentially generic: you'll want them to have a common syntax, semantics and implementation except for which classes (tables) and fields/properties (columns) they operate on. Selection criteria, joins, etc. will likewise follow common generic patterns. So you want to specify their syntax and semantics once and for all, and then vary only the details that actually vary. This is what a common query language such as SQL buys you (but a functional paradigm, e.g. LINQ, has the same advantage).

>If you only have five different ways to query, you will only need five
>different methods.

Yes, so you specify them as methods only if the methods are so few, and so specific, that they cannot usefully be generalized. This is rather uncommon. It depends on the type of application of course.

-- 
Reinier Post
Received on Sat Mar 08 2008 - 11:51:12 CET

Original text of this message