> Sharing a configuration object across entire application just
> to be able to get an Executor in return, is an anti-pattern,
> it is evil and every time when someone suggest to do so, an
> innocent kitten dies.
Well, you do have context objects like that all over the place:
- JDBC connections
- Hibernate (or other ORM) sessions
- File handles
- Network connections
Yes, they are evil. One of the main reasons for the existence of frameworks
like Spring is the injection of such "resource" objects.
However, they are unavoidable for the following purposes:
1) To allow replacing the context underneath a computation. E.g. run the same
JDBC on top of different databases.
2) To avoid recreating the context for every operation.
For Jooq, the litmus test is:
Would it be useful to have a variant of Executor that takes its parameters not
from a configuration object but from a set of parameters?
How "wide" would that interface be? ("wide" = "many" parameters, or parameters
with "complex interrelationships".)
Would you want to use overloading on Executor constructors? Would overloading
run into uniqueness issues?
In the latter case, you need a Configuration construction kit anyway; the best
remedy would be to make it do very little processing, postponing all the heavy
lifting to the point in time when the query is actually executed.
However, this approach also delays any error checking until execution time,
which is unhelpful for finding bug causes.
Designing such interfaces is a trade-off between a LOT of conflicting goals,
and sometimes it's the choice between killing kittens and seal babies; the art
of design is to find a compromise where you kill neither (but maybe somewhere
else a hyena baby starves - no matter what you do, some trade-offs simply do
not have an answer that can't be questioned).
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
