Can someone please explain the best way to solve this problem.

Suppose I have three classes


Person
Venue
Vehicle


I have a DAO method that needs to return some or all of these attributes from each of the classes after doing a query.

Please note, by requirements I am using one DAO for all three classes and no frameworks.
Only my own MVC implementation

How do I accomplish this? It seems very wrong to make a class PersonVenueVehicle and return that as an object to get the instance field, values.

I was taught that the database entities must be reflected by classes, if this is case how is it implemented in such a situation?

One of the fundamental constraints of HTTP and the central design feature of REST is a uniform interface provided by (among other things) a small, fixed set of methods that apply universally to all resources. The uniform interface constraint has a number of upsides and downsides. I'm quoting from Fielding liberally here.

A uniform interface:


is simpler.
decouples implementations from the services that they provide.
allows a layered architecture, including things like HTTP load balancers (nginx) and caches (varnish).


On the other hand, a uniform interface:


degrades efficiency, because information is transferred in a standardized form rather than one which is specific to an application's needs.


The tradeoffs are "designed for the common case of the Web" and have allowed a large ecosystem to be built which provides solutions to many of the common problems in web architectures. Adhering to a uniform interface will allow your system to benefit from this ecosystem while breaking it will make it that difficult. You might want to use a load balancer like nginx but now you can only use a load balancer that understands DRAFT and CURATE. You might want to use an HTTP cache layer like Varnish but now you can only use an HTTP cache layer that understands DRAFT and CURATE. You might want to ask someone for help troubleshooting a server failure but no one else knows the semantics for a CURATE request. It may be difficult to change your preferred client or server libraries to understand and correctly implement the new methods. And so on.

The correct* way to represent this is as a state transformation on the resource (or related resources). You don't DRAFT a post, you transform its draft state to true or you create a draft resource that contains the changes and links to previous draft versions. You don't CURATE a post, you transform its curated state to true or create a curation resource that links the post with the user that curated it.

* Correct in that it most closely follows the REST architectural principles.
