As repository is a concept derived from Domain Driven Design, thinking about database tables is the wrong approach. By definition you access aggregate roots from a repository. Effectively a repository is simulating a collection of these.
Now what forms an aggregate root? Probably even more interesting: what does not? That's, of course, highly dependent on your domain, but let me give you an example here. An Order
containing LineItems
usually is modeled as an aggregate root. This is due to the composition nature of the Order
. A LineItem
would not exist without a surrounding Order
.
Usually the persistence access mechanisms should follow the domain principles. Thus, you'd model both Order
and LineItem
as @Entity
classes but only create an OrderRepository
, as they form the aggregate root and effectively control the consistency rules within the object graph.
We also strongly recommend not to use the store specific repository base interfaces as they - as the name suggests - expose store specifics (e.g. flush()
) to the clients of which they shouldn't be aware, if possible. Read more on that in my answer here.