MVC: modèles entièrement peuplés ou modèles partiellement remplis?

Celui-ci me hante depuis si longtemps. Lors de la programmation MVC, quelle est selon vous la meilleure pratique de programmation? Doit-on utiliser des modèles entièrement remplis ou partiellement remplis, surtout quand je sais que pour cette tâche particulière, je n'aurai besoin que de 2 champs de l'objet modèle qui en a 5 autres?

Parfois, il semble criminel de remplir une liste de 20 objets modèles avec toutes les valeurs de la base de données lorsque vous savez que vous n'en aurez besoin que de quelques-uns.

Bien sûr, le modèle partiel signifie que vous devrez écrire une méthode de plus dans votre DAO en dehors de celle qui récupère tout. Ce qui signifie plus de code à maintenir?

D'un autre côté, tout tirer de DB avec des modèles entièrement peuplés signifie qu'une méthode sert tout, mais cela va évidemment vous donner des frais généraux de performance.

Je peux voir ORM (comme Hibernate ou ActiveRecord of Rails) favoriser les tendances dans la programmation MVC et les bases de données comme les modèles complets BigTable de Google est une tendance acceptée. Mais que se passe-t-il si vous utilisez toujours un bon vieux JDBC?

Le matériel est bon marché, le développement est coûteux. Est-ce vraiment vrai même lorsque l'application doit évoluer à quelques centaines de milliers de demandes par heure?

Vous avez deux options:

1) Laissez certains champs du modèle vides

2) Créez un modèle "lite" supplémentaire pour votre situation spécifique

Lequel choisir dépend à nouveau des deux choses:

a) Combien de champs du modèle "complet" vont être ignorés

b) Combien de fois ce modèle "léger" sera instancié

S'il n'y a que quelques champs ou plus qui peuvent être remplis, il est normal de choisir 1).

Si b) n'est qu'une situation individuelle exceptionnelle, il est peut-être inutile de créer un modèle supplémentaire uniquement pour un cas d'utilisation.

Une autre approche consiste à définir un modèle "allégé" et à en hériter le modèle "complet".

Si votre vue n'a besoin que de 2 propriétés du modèle, vous avez (probablement) le mauvais modèle pour ce cas d'utilisation! Je chercherais à créer un modèle adapté à la vue, à enregistrer les recherches de base de données supplémentaires et à ne remplir que les données dont vous avez besoin. Si une vue ultérieure a besoin de plus de détails, vous devez demander, puis-je obtenir les données supplémentaires plus tard ou dois-je les obtenir toutes à l'avance ...

Vous pouvez également envisager une sorte d'évaluation paresseuse, de sorte que les valeurs sont remplies lorsque vous en avez besoin. Cela peut bien fonctionner, mais c'est évidemment plus de travail et peut finir par provoquer plusieurs allers-retours vers la base de données, ce qui n'est pas génial si vous finissez souvent par le faire.

Cela dit, si vous sélectionnez essentiellement quelques champs supplémentaires dans une table ou une vue, le coût d'obtention de ces données supplémentaires est, à toutes fins utiles, nul (OK, il y a plus d'octets sur le fil, mais les coûts les plus importants sont probablement être dans la création et la suppression d'une connexion), donc s'il y a une chance que vous ayez besoin de données supplémentaires, je remplirais probablement le modèle une fois que vous êtes satisfait, vous avez le bon modèle .

Le matériel est bon marché, mais aucune quantité de matériel ne peut faire bien fonctionner un mauvais design.

Le modèle n'est pas un DAO.

Et une autre chose: si vous dites que vous avez 20 modèles (clients, de votre exemple), alors ce n'est pas un modèle MVC. Le modèle de domaine ne correspond pas directement à une seule ligne de table. Au lieu de cela, il devrait être responsable de toutes les opérations effectuées avec vos «clients».

Dans votre exemple, "Client" n'est pas un modèle de domaine, mais simplement un objet à l'intérieur du modèle.

Quant à l'interaction avec la base de données, cette responsabilité devrait être déléguée à un objet mappeur de données , qui devrait savoir comment stocker et récupérer vos instances de la classe Client.