> > 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). >
Very important sentence in this discussion, because the powerful code-generation was (besides the typesafety in queries) the second driver that pulled me to jOOQ (DAOs included ofc). So if we have this, I'm fine with deprecating DAOs (although I'm using them). Like others already wrote: they give you CRUD for free in many usecases and thus speed up development. Let me jump to the initial post: This list has debated DAOs time and again in the past. There had been many > feature requests, extension requests, and people criticising jOOQ's use of > the Java final keyword as it prevents the application of the open-closed > principle, at least in those people's understanding. My understanding is a > bit different: > https://blog.jooq.org/2017/03/20/the-open-closed-principle-is-often-not-what-you-think-it-is > > In fact, people bumping into jOOQ's usage of final in this area simply > shows that the design (or the vision) is insufficient in this particular > case. Otherwise, there would be no desire to "hack" additional behaviour > into the existing API through what I believe to be a highly overrated tool > of object orientation: Concrete class overriding. > If there is a lot of discussion around that topic, doesn't that also mean, that plenty people are using it? So it could also be a discussion about how to implement a better DAO-extensibility. -- 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.
