Hello Chriis, I have been questioning myself many years on that particular subject.
> Essentially: > - What are Record objects? > - Are these Record objects oriented toward the database access > (persistence layer) or to be passed to the business layer? > Imho, records are objects that reflect the state of a particular entry in a DB table. Past the very simple cases, they make poor business objects. However they are perfect if you don't mind sacrifying some object orientation and adopting a more procedural coding style. This is often unavoidable in service oriented apps anyway. As for passing them accross layers, I have no problem with that. I usually create DAO classes for the basic stuff ( eg: findById, findByCountry) but then I don't mind my service classes dealing with Factory directly. It is often necessary because I combine batch updates, stored procedure calls, arbitrary joins. If I had to abstract away all the jooq stuff in a lower layer to hide it from the service layer, this layer would need to be so generic that I would end up reinventing Factory. I think that forcing yourself into an absolute separation of data access and business logic is not always a good idea, past the most simple cases you can easily end up with a mix of both, the drawbacks of both but the benefits of none. And again: > - What is the recommended way with jOOQ to consume/create/feed business > objects? > > You could wrap them in more interesting entities and provide smarter accessors that can do some basic validation. Instead of calling you record class setStartDate and setEndDate that accepts null and don't check for consistency, you could opt fo a defineDuration(Date start, Date end), that can do basic validation. Also you can provide a meaningful constructor. That is already better, but things become much more complicated if operations on the business objects require database access or involve records from many tables. Then again you'll have no choice but to use services for performing some operations and becoming more procedural / service orientated. Even by using tools like hibernate that have caching, lazy-loading and such stuff it's very hard to design nice object oriented entities as soon as many tables and relations are involved, it at least it's difficult to do it efficiently (loading and manipulating and finally persisting your business objects one by one sure is nice, but what if you suddenly need to batch update 50'000 of those? Well you'd forget the OO stuff and write a service ) -- 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/groups/opt_out.
