On inheritance of the domain model [Was: Generating "FooRecord extends BaseFooRecord" like PHP Propel?]

[Lukas Eder]

2013/8/20 Durchholz, Joachim <Joachim....@hennig-fahrzeugteile.de>

>>> Joachim! Let's solve tomorrow's problems... tomorrow :-)
>>
>> Well, it's today's problem for me.
>> Or would be, if I had started transitioning to Jooq.
>>
>I'll restart counting milliseconds from zero on that day (should it come) ;-)

Ah well, it seems I overlooked the sarcasm "I'm looking forward to tons of feedback from you, once you're starting to delve into details..."
Silly me.

Agh, I've gone too far again... I'm sorry.

Well okay, I'll stop annoying you with a use case you obviously don't care about.

I already have that with Hibernate, so I guess switching to Jooq isn't going to be that much of an improvement, and probably not worth the effort.

Good that that's settled. Good luck and take care.

Thank you. If you're still interested in on-topic discussions about your ideas, feel free.

[Christopher Deckers]

Lukas, Joachim,

Ah well, it seems I overlooked the sarcasm "I'm looking forward to tons of feedback from you, once you're starting to delve into details..."
Silly me.

This looked to me more like tongue-in-cheek or teasing. I do that all the time and I know Lukas does it to. That is not personal at all, rather, to keep the discussions light and witty.

But come back to the discussion! I am very interested in this subject, so I would really like you to go on explaining your approach.

 

The proposal is to move field accessors into superclasses of the business classes (for good reasons actually).
The issue is that if the business class is already a subclass of another business class, it would now need to inherit both from there and from the new field accessor class. Java does not offer multiple inheritance in that way, so this will fail with compiler errors.

Essentially:
- What are Record objects?

- Are these Record objects oriented toward the database access (persistence layer) or to be passed to the business layer?

And again:

- What is the recommended way with jOOQ to consume/create/feed business objects?

Please share your ideas and expectations!

Cheers,

-Christopher

[Stéphane Cl]

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 )