As you see, the solution might not be very satisfying. The problem of data access at all is, that we have to consider many different aspects which make code not 100% reusable. It's about transactions and locking, and the way e.g. ORM maps a relational database to objects and vice versa.
Mostly if you try to write architecture components, trying to solve the problem you'll soon notice, that you just move the problem to another place. The reason is simply that a bottom-top approach as your question is, is a bad idea.
What we want is an agile top-down strategy. You will see, that most of the accesses are read-only, which (nearly) means no locking and no transactions. Some writes are field updates which must not be synchronized and a few inserts into different tables might need locking and should be in a transaction.
Now to your variants:
Move all methods, even slightly different, as a separate methods into DAO class. This makes DAO complex, their method names will be very long, it would be hard to find correct one.
violates OCP. there should be one entity/table-definition and querybuilding components around it but only depending on the entity itself. That means no large accessor classes.
Forget about fetch joins. Setup application to perform loading when needed (lazy loading). This will reduce number of methods, but database access will be much less effective and transaction must span across entire request, not just controller code.
lazy loading is cool for code which should be more readable focused than performant, e.g. backends with small lists and a few administrators. Not a good idea for uncached permanently accessed frontend pages.
Put complex logic into method when needed. E.g. supply boolean parameters fetchSomething. And method will tweak query according to those parameters. Method implementation will be very complex as I would have to either build query string from pieces or use very cumbersome Criteria API. Method will be hard to read and understand.
parameters like offset and limit are okay, but boolean parameters whether to load sparse or full is too much overhead in code, which might leads to magic behavior.
Leave as is. I generally like this approach. It leads to some code duplication, but not very much and queries are declarative so I don't see much problems with that. The main problem is lack of testability. To test controller I would need to prepare a database, because there's no (or I didn't found) complex JPA mock implementation with supplied in-memory data.
For integration tests yes, you need to save some data to your database (you can use e.g. sqlite). For unit tests no, you mock the service layer according to your controller input and test how controllers behave.
I wonder what approach used in complex projects? I saw 4-th approach and I saw once very complex in-house ORM based on Hibernate.
Big projects actually use service orientated setups on the highest level and use ORM or plain queries according to their needs. There is no one and only solution.
I'm talking now about so-called "repository pattern". I don't really understand what people mean by "service layer" and never saw any need with that, so currently the question is about data repository classes.
IO-Applications are nearly equal. There is a request and a response. The controller is responsible for collecting data from the request to call a service which produces data which will be collected and returned. E.g. business logic and all the use-cases of the software are 100% part of the service layer. Unit-testing the controller by mocking the services is much easier.
"Repository pattern":
I've spent a lot of time on Doctrine and PHP and over the last years I dropped the repositories, because 1% are simply repository operations like a list of countries ordered by name, 80% are more complex DQL or querybuilder queries, also with flat results and the rest are SQL queries I cannot write with DQL.
Result of most of the queries are table with columns from different joined tables. ORM would not makes sense at all, thus I don't use repositories anymore, but a clean service layer and a couple of data access services.
Stack Overflow uses a micro-orm. Unlike Hibernate, it's just a thin veneer around SQL queries.
Answers to your questions:
By writing a SQL query.
It can vary from one line of code to about 40. Having ready-made DTO's does help.
The DTO looks the same. You might run 2 queries instead of one, and lazy-load the second one.
In Javascript, JSON translates directly to Javascript objects. For other languages, you can use something like Newtonsoft.Json to translate the JSON to objects in your language of choice.
Here is some example code:
var result = database.ExecuteSqlQuery<Customer>(
"SELECT * FROM Customer WHERE CustomerID = {0}", customerID).FirstOrDefault();
Where ExecuteSqlQuery returns a List of Customer objects. Customer is a class containing public members corresponding to some or all of your columns in your query.
Dapper is capable of running queries just like this one. It will return a collection of objects of a specific type, or a collection of dynamic objects.
Best Answer
Both Hibernate and EclipseLink use the Proxy design pattern to implement lazy/eager loading of entity relationships. Proxies are weaved into Java bytecode at build time (statically) or at runtime (dynamically) - basically enhancing your Entity POJOs. Other features, such as dirty checking are also weaved into bytecode.
This is an application of Aspect Oriented Programming (AOP). All the same pitfalls (e.g. unexpected classes at runtime) and advantages (e.g. cleaner source code, runtime code injection) apply.
So the question is, what are the alternatives? You could disable weaving and implement the same features (lazy loading, dirty checking, etc.) in your own code - no runtime surprises, but increased development effort.
As a rule of thumb, use annotations, avoid runtime entity class inspection and trust Hibernate or Eclipselink code weaving to deliver what you want. Note that you always have the option to implement your own proxies, etc. if complexity requires it.