I never found the DAOs and Pojos useful and disabled code generating them. In the past, I was also concerned that they'd promote an ORM world view, leading to requests for JPA, rather than embracing SQL.
I prefer to use DSLContext directly and never heard a complaint (only praise) from coworkers when they used jOOQ. I sometimes use the record types, but only for internal logic. Instead I use jsonSchema2Pojo (or in the past, protobuf) to generate my service types. The fetchInto() mapping is usually enough and when not the custom mapping is pleasant enough. I've often written custom repositories to extract the query logic from the services to simplify the code. But when the class is well factored, like a background job, I'm more inclined to embed the query rather than bloat a repository with one-off usages. I can understand why some would want to use the Pojo codegen and return the results directly. To me that couples the service schema to the data schema, which may only match one-to-one early on. By having a service schema its easier to refactor and be less likely to break the external contract by mistake. The amount of work to write a schema, e.g. json schema, is trivial and it is nice to know exactly what the payload looks like and, optionally, run it through a validator. These days I use a hybrid nosql / sql data model in Postgres, resulting in a high usage of json schema for generation the UI and dynamically configuring a backend processing pipeline. If I had started with DOAs then I'd have needed to move away regardless. On Monday, March 20, 2017 at 9:47:07 AM UTC-7, Lukas Eder wrote: > > Dear group, > > The DAO type has been haunting this list ever since it was added to the > library in version 2.4 (2012). At the time, it was a quick win over a > competing library that already had the feature. They were extremely easy to > implement in jOOQ. > > However, DAOs (much like repositories, e.g. in Spring Data) are some of > the most opinionated things in software. As such, they require either: > > - A very strong opinion on the matter (duh), but jOOQ doesn't have one > - An extremely versatile design that satisfies all needs, which is > probably not possible > > 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. > > Non-essential, yet incomplete features distract us from what jOOQ really > does well: SQL language abstraction. And this causes great harm to the > library as I'd really rather be implementing features like MULTISET, > SQL's temporal validity, better XML and JSON support, etc. etc. than > debating DAOs. > > *I am thus proposing the deprecation of the DAO type per jOOQ 3.10, and > its removal per jOOQ 4.0:* > *https://github.com/jOOQ/jOOQ/issues/5984 > <https://github.com/jOOQ/jOOQ/issues/5984>* > > I would like to invite you to join this discussion either to: > > - Confirm that you agree with this move > - Request we continue supporting DAOs (in case of which: please illustrate > why they're a killer feature for you) > > Best Regards, > Lukas > -- 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.
