Hi Lukas,
Thanks for your post. I never replied here. After a couple of months of
using jOOQ I thought I'd post an update.
Originally I was looking for some Spring Data functionality because that
really made things simpler when using JPA.
But I've found out that writing queries and repositories with jOOQ is so
easy and straightforward that I don't actually miss the Spring Data
features. At least for our case this is true where we have a modest number
of database tables, model classes and queries.
At the moment we are trying a design where we create "specialized" model
classes or DTOs for single use cases where needed. For the mapping we are
using custom mappers, which is ok as well for our amount of models. But
thanks for the Michael Simons link, I'll keep that approach in mind.
As you said, in this way we are losing the lifecycle information, but for
the moment we can live with that and e.g. always send the full data back
when updating a record.
I've never done this kind of design (which specialized models/DTOs), so it
will be interesting to see how it holds up as the code base grows.
In summary, I've found it very easy and also fast to work with jOOQ. I'm
quite happy with the existing Spring Boot integration (saves some
configuration headache), and so far I don't miss any "CRUD helpers", since
we are doing only very little pure CRUD anyway.
Cheers
Janne
On Wednesday, 7 September 2016 19:09:24 UTC+2, Lukas Eder wrote:
>
> Hi Janne,
>
> Thanks very much for your interesting questions. Disclaimer here is that
> we're entering "opinion land" very deeply. There isn't really a truly
> correct approach at separating concerns in these areas, only approximations
> with tradeoffs. For instance, the tradeoff of not "leaking" jOOQ's
> UpdatableRecords ("ActiveRecords") outside of a "repository" is that you're
> losing record lifecycle information (i.e. what record attributes have
> really changed). But that might be perfectly fine in your case.
>
> What particular parts of Spring Data's core / commons "magic" are you
> looking into reusing?
>
> As far as CRUD and mapping is concerned, jOOQ ships with a
> DefaultRecordMapper [1], which is applied automatically when calling
> Record.into(Class) or Result.into(Class). Michael Simons has written an
> interesting blog post [2] about how to enhance jOOQ's default behaviour for
> more complex mapping.
>
> You can also use jOOQ's DAO feature, which to some extent competes with /
> replaces Spring Data's repositories [3]. They implement a lot of CRUD
> convenience - although, with no magic.
>
> Of course, as your domain objects don't map 1:1 to tables, you will
> probably want to follow an approach similar to Michael Simons's approach.
>
> I hope this helps. If you have any additional questions about any details
> of the above, please do ask and I'll be very happy to help.
>
> Cheers,
> Lukas
>
> [1]:
> http://www.jooq.org/javadoc/latest/org/jooq/impl/DefaultRecordMapper.html
> [2]:
> http://info.michael-simons.eu/2015/09/09/jooq-and-spring-manage-your-recordmappers-as-components
> [3]: http://www.jooq.org/doc/latest/manual/sql-execution/daos
>
> 2016-09-06 16:29 GMT+02:00 Janne Hyötylä <jhyo...@gmail.com <javascript:>>
> :
>
>> Hello,
>>
>> We are starting a new project based on Spring Boot and have selected jOOQ
>> as our main DB querying framework.
>>
>> Does anybody have experiences with Spring and jOOQ? None of our devs have
>> used jOOQ so far, so I'm looking for best practices and possible pitfalls.
>>
>> Since Spring Boot already has a sensible autoconfiguration for jOOQ, that
>> is not an issue. I'm rather looking for infos on:
>>
>> * Integration with Spring Data? Is that possible? Can we reuse some of
>> the Spring Data repository "magic" to reduce boilerplate? I'm not talking
>> about Spring Data JPA but rather the "core" (or commons), since we at first
>> try to avoid JPA completely.
>>
>> * What are the mechanisms that can help us with CRUD and domain mapping?
>> We don't have too many tables and only a few simple CRUD operations (the
>> larger portion being complex queries and data transformations), but for
>> those cases, which patterns would be useful?
>> I wouldn't like to leak the jOOQ ActiveRecord objects above the
>> repository layer, since I think the consensus is that mixing ActiveRecord
>> and business logic leads to difficult-to-maintain code. And because our
>> domain objects don't necessarily map 1:1 to tables, jOOQs POJO or DAO
>> autogeneration might not produce the best results.
>>
>>
>> Thanks in advance for any insights!
>>
>> Best,
>> Janne
>>
>> --
>> 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 jooq-user+...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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 jooq-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
