How do you handle these common problems WITHOUT using an ORM and using straight JDBC (or equivalent)?

Question

Wnen using just JDBC, I typically have to think about the following problems. I don't think too hard and just make something work, but I am wondering how people handle these without an ORM or other library.

1. Eager vs Lazy Loading: Do you just have a single domain object and have the dependent children be null and make it the responsibility of the caller to recall the DAO to load these children when needed? Or do you just use multiple transfer objects for the same domain object? This also means that you would have to have maintain separate SQL queries for the eager case and the lazy case.

2. Domain objects and transfer objects: Do you even need both domain objects and transfer objects? For the above case, it might be easier to accomplish with different representations of the domain objects via transfer objects. Finally, if using transfer objects, would related objects be "detached"? In other words, if you have a class Parent with multiple Children, would Parent have an instance of a Collection of Children, or would these be separately requested?

3. Assigning id's: What I have done so far is to bundle in a transaction and then assign the id's at the end. However, this requires a public function to set the id...

4. Cascading: I guess the only choice is to do this manually...

There are more, but this is all I can think of now.

EDIT: As to why I ask this question, you know how some development teams are "afraid" to use ORM's or don't like them for whatever reason (usually because they don't understand them), so sometimes JDBC is your only choice...

Answer 1

Well, the bottom line is that there are various solutions to each issue, and the right one for you is going to depend on the context: there is no one-size-fits-all approach to speak of.

For number three for example, we have a table which maintains a unique id counter for each type (one row per entity type): when you want an id, select the current value for a type then increment it in the database. This solution is simple but doesn't scale that well: if you want to improve it then you can have the application layer bulk allocate a load of these ids (say 50 at a time for each type) and then hand them out as needed when inserting new data, only returning to the db when it's pool has been exhausted. This is essentially an emulation of something like Oracle's sequences.

For number four, each entity class (classes which wrap a single table) that has a relationship with another entity type is responsible for cascading deletes etc.

In the end an ORM is just an abstraction, so if you look under the hood, all these problems have been solved by the library implementors. In this case you just have to do the legwork!