Cela dépend de ce que vous entendez par logique métier. Toute "logique" qui donne un sens au contenu du modèle devrait être dans le modèle. Dans la question liée, la réponse la plus votée semble définir la "logique métier" comme tout ce qui concerne les données; cela semble logique du point de vue que les données d'une entreprise sont ses affaires!
J'ai déjà vu un exemple du créateur de Rails (je pense) qui parlait exactement de cela, sans mettre de "logique commerciale" dans le modèle. Son exemple était une classe de contrôleur et une méthode d'enregistrement et de connexion d'application - un mot de passe fourni en texte brut était crypté avant d'être inséré ou interrogé dans le modèle (une base de données).
Je ne peux pas penser à un meilleur exemple de quelque chose qui n'est pas une logique de contrôleur et qui appartient directement au modèle.
Le modèle pourrait être une interface avec une myriade de magasins de données, atténuant les problèmes de portabilité. C'est ici que l'on pourrait trouver une confusion sur le fait que l'interface de modèle soit réellement le "contrôleur".
De manière générale, le contrôleur lie le modèle et la vue (qui sont les éléments essentiels de l'application). Dans le développement de Cocoa, il peut être simpliste au point que le contrôleur soit géré via l'interface graphique XCode (objets et liaisons de contrôleur).
La section "Design Patterns" du GoF sur MVC, vaguement citée:
Le triade de classes MVC est utilisé pour créer des interfaces utilisateur dans Smalltalk-80. Le modèle est l'objet d'application, la vue est sa présentation à l'écran et le contrôleur définit la façon dont l'interface utilisateur réagit à l'entrée de l'utilisateur. MVC dissocie les vues et les modèles en établissant un protocole de souscription / notification entre eux. Le diagramme suivant montre un modèle et trois vues. Nous avons laissé de côté les contrôleurs pour des raisons de simplicité.
MVC est tout au sujet des interfaces utilisateur. L'accent est mis sur le modèle et la vue - définition et affichage des données. Notez le "protocole abonnement / notification" - c’est là que votre contrôleur entre en jeu. Vous pouvez créer toutes les vues souhaitées; tant qu'ils adhèrent au protocole, vous ne devez jamais toucher le modèle ou le contrôleur.
Si vous parlez de développement Web en particulier, à mon humble avis, de nombreux frameworks Web populaires utilisent rapidement le terme MVC et ses définitions de composants.