Thank you very much for your feedback, Celestino. Interesting, I would not have thought that among all features, the DAOs would be what sets jOOQ apart from QueryDSL :) There seem to be much more interesting advantages (in my opinion), but great to know that it was the DAOs for you.
Do not get me wrong, I do not at all oppose the idea of having a DAO "layer" or concept (or more generically, a Repository pattern) in an application. I think that's a great idea, and for some people, generating them in a 1:1 fashion per table is also very helpful. The idea of deprecating the current jOOQ DAOs stems from the fact that they are much too opinionated for the jOOQ core library, and they would be rather easy to maintain outside of jOOQ. In fact, they hardly do anything (yet for many people, they're doing it wrong), so the problem for us is not the technical maintenance, but the support effort that goes into them. Nevertheless, I do appreciate the need of some jOOQ users to have generated DAOs, and I think we might be able to cover your needs in a version 4.0 of jOOQ by implementing a better, more extensible code generator that makes generating custom classes from your database really easy (it's already easy with the existing generator, but it wasn't designed for extension). I will further comment inline. 2017-03-22 22:28 GMT+01:00 <[email protected]>: > Hi > > In my case, the generation of the DAOs that brings me jOOQ was one of the > main decision to choose it instead of QueryDSL for example. > When you work in a medium/big project that manages information stored in > relational database, where is the "best ubication" to include > the queries? the services layer? my "own specific" layer? in that case, > you will see how the size of the classes included in this layer will > grow dramatically. > > And it is a very bad design to spread the queries among several files > without a strict criteria, for example, include a sql to get the list of > users > in the RoleService or something like that. > I absolutely agree. But again, most of jOOQ is really unopinionated about these things, whereas DAOs are highly opinionated. They just happen to work well enough for you, but not for many others. > jOOQ offers the possibility of generate DAOs or not, every developer can > choose it in the XML configuration file. So if you prefer to use > DSLContext directly or develop your own DAO, then go ahead. Currently, > jOOQ allow you it. > > Unfortunately, not always I can write all required test (due to deadlines > and similar issues) but when I can do it, the DAO layer offers me the > possibility to test only this layer and verify "all required queries" by > my project using a database used for testing purpose. And when I want > to test "upper layers" like services or controllers for example, I only > need to deal with the "specific business logic" added by this layer. > Absolutely. Again, I do not want to argue the benefits of implementing a layered architecture. This is just about the hard-wired opinion that goes into having a DAO layer in what is otherwise only a SQL API. Thanks again for your feedback. It's great to hear that you've found DAOs so useful, and if we go on deprecating them, we'll certainly think of your use-case of having an easily generateable DAO layer when improving the code generator. -- 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/d/optout.
