It’s sad that it took getting so far down the thread before somebody pointed out the obvious program design flaw.
If you’re digging many levels down into your datamodel from high up for lots of datapieces, it’s probably the case that both the data is unnecessarily framented and the code design itself doesn’t have proper OO isolation of responsabilities.
If you’re designing for performance (a well know raeson to screw OO design), then the datamodel itself would be a lot flatter (because you get more performance on the DB by trading it for space), whilst if you’re not then you break the thing into parts as you have functions were you fetch intermediate objects into memory and handle the data in them (a Visitor Pattern would probably make this a lot cleaner).
I bet whomever designed the datamodel isn’t the same as those doing the coding.
It’s sad that it took getting so far down the thread before somebody pointed out the obvious program design flaw.
If you’re digging many levels down into your datamodel from high up for lots of datapieces, it’s probably the case that both the data is unnecessarily framented and the code design itself doesn’t have proper OO isolation of responsabilities.
If you’re designing for performance (a well know raeson to screw OO design), then the datamodel itself would be a lot flatter (because you get more performance on the DB by trading it for space), whilst if you’re not then you break the thing into parts as you have functions were you fetch intermediate objects into memory and handle the data in them (a Visitor Pattern would probably make this a lot cleaner).
I bet whomever designed the datamodel isn’t the same as those doing the coding.
To be fair, probably hardly anyone actually looked at the code. And now that I did, I think this is compiled, not source code.