How many models for many to many relations

Having three tables:
- pages
- users
- users per page

how many models would you create to manage them?
I typically only create two models, one for pages and one for users.
Would you also create a third model for the relationship table?

I prefer to use one, and then have my Entity use the related model to get its relations. This will be rough bc I am mobile but something like:

PHP Code:

UserModel:: $returnType = 'App\Entities\User'

User::getPages(): Page[]
    return model(PageModel::class)->findForUser($this->id);

PageModel::findForUser(int $userId): Page[]
    return $this->select('pages.*')
        ->join('pages_users', 'pages.id = pages_users.id')
        ->where('user_id', $userId)
        ->findAll(); 


I prefer to use one, and then have my Entity use the related model to get its relations. This will be rough bc I am mobile but something like:

PHP Code:

UserModel:: $returnType = 'App\Entities\User'

User::getPages(): Page[]
    return model(PageModel::class)->findForUser($this->id);

PageModel::findForUser(int $userId): Page[]
    return $this->select('pages.*')
        ->join('pages_users', 'pages.id = pages_users.id')
        ->where('user_id', $userId)
        ->findAll(); 


Found this old thread with Google...
Tatter\Relations seems heavy handed for my use case, in which there is only one Entity; which has itself several different relations. I like the approach above, but don't totally understand how to transfer the concept to my application.

@MGatner does your pseudocode suggest that we extend all the relation-models involved with methods to support the Entity-level methods which populate the instance attributes? Or keep it all in the Entity's own model and do several DB connections from there to the related tables?

My sense is that with the approach you wrote above, we'd keep the Entity population spread over several models, but I wan to know what you'd suggest 2 years later.