Thanks very much for your comment, Jens 2017-03-30 9:42 GMT+01:00 jklingsporn <[email protected]>:
> 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. > Excellent, so this is clearly understood now (and I'm very glad I asked). While most people agree that DAOs aren't useful in complex applications, they do help speeding up things in simple ones (at least for some people). We'll keep this in mind, and probably postpone deprecation until the new code generator is properly laid out. > 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. > Yes, plenty of people are using it, but not necessarily because they like it. More often, they have (or had) expectations (explicit or implicit) towards the feature, and then spent a lot of time figuring out that it's incomplete. There are now two options: 1. "Improving" DAOs (and I feel this is almost impossible, because it'll always be implementing only one opinion out of many) 2. Removing DAOs and leaving the topic to others. Regarding bullet 1): Think of Spring Data's Repositories, which have features like translating english method names to SQL queries. That's nuts (in my opinion). Sure we can save a couple of seconds writing the actual SQL query, but we're still writing a query, and we're writing it in a rather mediocre "language" that will not be good enough sooner than later. Moreover, that "language" will probably be an important reason for performance problems, as you cannot really tune those "queries" (e.g. how to avoid SELECT *). In fact, such a "language" is proof that some sort of query specification (which is likely storage specific) will inevitably leak outside of the repository, which breaks the very purpose of a repository. To be storage agnostic. The same is true for DAOs. See, that's just my opinion. Yours may vary and I won't get in the way of DAOs (or repositories) in jOOQ client code. But I don't like jOOQ to be an opinionated framework, because that means, people might be less inclined to use it once they disagree with the opinion (because they waste time with jOOQ rather than saving time with jOOQ). -- 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.
