Hi Lukas, JOOQ 2.6 is great, because it does not goes in a way when one wants to build application following good practices and patterns like Dependency Injection. What is that all about? It is all about not mixing of concerns. A class should focus one one thing. If my class talks to database through JOOQ, it should not care how JOOQ finds its way to the database. It is completely irrelevant to that class. This is what's most important when following the Inversion of Control principle: ask for things you really want. In my case, using 2.6.x names: my class wants an instance of FactoryOperations, so I declare dependency on it. I do not care how is that object created. I do not care who and where handles stuff like transactions, etc, etc... All I want is the container (EJB/CDI in my case) do THEIR'S job (object creation, lifecycle manage, transactions and whet else), and my class do IT'S own job. That means, I do not want my class to be responsible for FactoryOperations instance creation. I do not want to declare dependency on some Configuration object instance only because the JOOQ factory needs that.
Bottom line is: do not split all the DSL into several classes. Keep them all in one place, so one import static should handle it all. But please, do not drag the FactoryOperations (or whatever it is going to be named in 3.0) object instance creation within. I would love to be able to explain this thing better. Please, let me know if you are still unconvinced. Regards, Witold Szczerba On 5 April 2013 17:23, Lukas Eder <[email protected]> wrote: > 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. > > > -- 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.
