Comment concevoir des modèles de la bonne manière : orientés objet ou orientés « package » ?

Je sais qu'en POO, vous voulez que chaque objet (d'une classe) soit une "chose", par exemple. utilisateur, validateur, etc.

Je connais les bases de MVC, comment les différentes parties interagissent les unes avec les autres.

Cependant, je me demande si les modèles dans MVC devraient être conçus selon la conception traditionnelle de la POO, c'est-à-dire, chaque modèle devrait-il être une base de données/table/ligne (solution 2) ?

Ou est-ce que l'intention est plutôt de collecter des méthodes qui affectent la même table ou un groupe de tables liées (solution 1).

Exemple pour un module de carnet d'adresses dans CodeIgniter, où je veux pouvoir "CRUD" un contact et l'ajouter/supprimer à/d'un groupe de contacts CRUD-able.

Solution des modèles 1 : regrouper toutes les méthodes associées (pas un objet réel, plutôt un "paquet")

class Contacts extends Model {

     function create_contact() {)
     function read_contact() {}
     function update_contact() {}
     function delete_contact() {}

     function add_contact_to_group() {}
     function delete_contact_from_group() {}

     function create_group() {}
     function read_group() {}
     function update_group() {}
     function delete_group() {}

}

Solution de modèles 2 : la méthode OOP (une classe par fichier)

class Contact extends Model {
     private $name = '';
     private $id = '';

     function create_contact() {)
     function read_contact() {}
     function update_contact() {}
     function delete_contact() {}

}

class ContactGroup extends Model {
     private $name = '';
     private $id = '';

     function add_contact_to_group() {}
     function delete_contact_from_group() {}

     function create_group() {}
     function read_group() {}
     function update_group() {}
     function delete_group() {}

}

Je ne sais pas comment penser quand je veux créer les modèles. et les exemples ci-dessus sont mes vraies tâches pour créer un carnet d'adresses. Dois-je simplement regrouper toutes les fonctions dans une seule classe. alors la classe contient une logique différente (contact et groupe), elle ne peut donc pas contenir de propriétés spécifiques à l'un ou l'autre.

La solution 2 fonctionne selon la POO. mais je ne sais pas pourquoi je devrais faire une telle division. quels seraient les avantages d'avoir un objet Contact par exemple. Ce n'est sûrement pas un objet User, alors pourquoi un contact devrait-il "vivre" avec son propre état (propriétés et méthodes). Parce que j'ai tendance à penser comme ceci : si quelque chose a besoin d'un état, alors je crée une classe OOP afin que les méthodes puissent affecter l'état ou d'autres choses basées sur l'état.

Les modèles devraient-ils donc aussi être « avec état » ? s'ils ne nécessitent aucun état, pourquoi devrais-je le créer selon le modèle OOP. alors je pourrais simplement tout regrouper comme la solution "package".

Vous avez connu des gars avec la POO/MVC, veuillez nous éclairer sur la façon dont il faut penser ici dans cette tâche très concrète (et en général lors de la création d'un modèle)

EDIT : pensez aux contrôleurs dans MVC. ils sont créés selon la solution « package ». Ça me fait penser...