2013/4/5 Witold Szczerba <[email protected]>: > On 5 April 2013 15:59, Lukas Eder <[email protected]> wrote: >> >> 2013/4/5 Witold Szczerba <[email protected]>: >> >> >> > >> > As to the: >> > with(configuration) >> > .select.... >> > >> > Is this a real use case? I mean, in any given class responsible for >> > talking >> > to database, why should I care about configuration object, if all I need >> > is >> > the other object (factory instance), exchanged for configuration >> > instance? >> > >> > I believe (am I alone?), each class should ask only for things it does >> > care >> > for. In the case above, we do not care about configuration, we care >> > about >> > that contextual factory instance. All we use configuration for, is to >> > quickly exchange it for something else. That means we should never ask >> > for a >> > configuration, but the contextual factory instance (or a provider of >> > that) >> > instead. >> >> The point is that a contextual factory needs the context (= >> Configuration) somehow. >> > > You are right, the contextual factory needs configuration. But users of > contextual factory should not care. Of course, everyone can use the JOOQ as > they like, but JOOQ should not go in a way when one is following the good > practices, which is not mixing the object creation with use. Also, if one is > asking for something which they are not directly using (configuration in > this case), then they are violating a Law of Demeter.
I'm not sure if I understand you correctly. What do you mean by "asking for something which they are not directly using"? I'm afraid, I'm a bit lost here... > All I am trying to say is that maybe we should not focus on how to make a > fluent language to describe the process of building the query _together_ > with the building of the contextual factory. I would split that as much as > possible. For example, if the static method "with(Configuration cfg)" is > going to be mixed with other static methods like max/min/nvl or other static > DSL methods, then I would suggest splitting that. I'm not so sure if general "best practices" also apply to jOOQ in these cases. jOOQ aims to be an internal domain specific language. If I could bend the rules of Java even more, I might actually add keywords to the Java language, which hide the fact that behind the scenes, actual methods are called. This "with(Configuration)" construct reminds me of Java 7's try-with-resources syntax, which adds great convenience Now, as you said (although you probably didn't mean the same thing), "users should not care". In my opinion, users should not care how the DSL is implemented, technically. I.e. they shouldn't go looking into dozens of classes for static import candidates. In that case, I think that putting "with()" together with "max()", "min()", "nvl()" is OK. Besides, I can see how users would ask for a facade "JooqDslAll", as Christopher suggested. Once we have the facade, we might as well inline everything... Let me know if I understood you wrong? -- 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.
