La Conception Orientée Objet Du Modèle-Vue-Contrôleur Est-Elle Mauvaise? [fermé]
les architectures OOD (Object-Oriented-Design) et MVC (Model-View-Controller) sont devenues les piliers de la conception logicielle moderne. Pourtant, j'ai récemment eu une discussion intéressante sur la façon dont les architectures MVC utilisent (et possilby même violer) principes OOD. Cette possibilité est en fait assez intrigante puisque les deux OOD et MVC sont destinés à atteindre plusieurs des mêmes objectifs: la séparation des préoccupations et la réutilisation du logiciel. Mais la question que je pose: ces deux stratégies de conception sont-elles en conflit direct l'une avec l'autre? comme j'ai utilisé les deux, dans la pratique, je commence à penser: très probablement oui.
je le dis parce que: appliquer une séparation stricte entre les modèles, les vues et les contrôleurs aboutit souvent à des architectures où les modèles sont implémentés comme muets récipients qui ne peuvent être manipulés que par des contrôleurs externes. Je soutiens que cela va directement à l'encontre de l'un des principes conception orientée objet: lorsque les objets contiennent des opérations qui effectuent les opérations nécessaires et les encapsulent selon les besoins. Par exemple, dans une architecture purement orientée objet, une hypothétique File classe contient des méthodes telles que open() et save(). MVC suggère que nous ayons deux classes File et FileManager (telle que la dernière contient le open() et save() méthodes). Pour moi: la conception MVC est assez désordonnée. Si vous avez besoin de créer un type plus spécialisé de File (pour gestion des fichiers qui circulent à travers un réseau sur open() ou save()), il suffit de sous-classifier File avec une classe appelée (disons): StreamedFile. Avec MVC, vous devez créer une autre classe de manager ou compliquer la conception de la classe de manager originale.
à Partir de cela, il s'ensuit que dans un système plus complexe, MVC pourrait avoir des effets désastreux à la fois sur la séparation des préoccupations et sur la réutilisation du code. Ou Pas? Peut-être que les modèles MVC pourraient être mis en œuvre sans la rupture d'INONDATION de principes? Ou est-ce que MVC est une approche fondamentalement défectueuse qui rend difficile la mise en œuvre de systèmes logiciels avec des composants à couplage lâche?
4 réponses
au contraire, une utilisation saine des MVC devrait encourager maigrichon contrôleurs et gras des modèles, de sorte que les modèles (les objets) sont là où l'action se produit (ce qui encourage lui-même l'encapsulation et d'autres bons principes OOP), et les contrôleurs sont simplement là pour pointer certaines requêtes dans la bonne direction vers les objets.
Rien dans MVC dit que Model devrait être stupide (anémique modèle). Je pense que c'est tout à fait approprié pour de riches Model les classes, qui éliminent le besoin de 'managers'.
cela dit, il est pratique courante d'utiliser ViewModel S pour passer des données à un View. ViewModel est essentiellement une projection de votre Model adapté spécifiquement pour un particulier View. Il peut être considéré comme ModelViewdu point de vue, une façade pour un riche Model; de sorte bien sûr, il ya beaucoup plus à un ModelViewModel.
Je n'appellerais pas MVC une architecture qui souffre autant que OOD. MVC est juste un modèle OOD qui peut être appliqué dans certaines conceptions. Ainsi, il simple ne rivalise pas avec OOD et c'est juste un de vos outils pour construire un bon ou mauvais design OOD. Tout comme un marteau ne rivalise pas avec la qualité de l'exécution en bois, le marteau, comme MVC, est juste un outil dans la boîte à outils de l'artisan.
il n'est pas non plus modèle qui facilite la mauvaise conception. Parce qu'une bonne conception OOD aura un bon séparation des préoccupations, le modèle MVC peut fournir que pour vous en séparant les préoccupations de présentation (vue) de la logique d'application (contrôleur) et la logique de domaine plus fondamentale (modèle). En tant que tel, c'est un bon motif OO qui est souvent appliqué dans les interfaces utilisateur. Mais il y a d'autres modèles concurrents qui pourraient également être considérés tout en faisant un bon OOD.
nous avons deux formes de MVC, Pull MVC et Push MVC (MVC basé sur un composant aka et MVC Legacy).
Push MVC se concentre sur la séparation des concepts, chaque ensemble model-view-controller gère un aspect de l'application et peut être conçu et développé par des personnes distinctes. Lorsque le système se développe rapidement, il fonctionne très bien, et ajouter des fonctionnalités est facile aussi. La réutilisation de Code dans des systèmes plus grands devient terrible. Essentiellement, seuls les modèles sont réutilisés.
Pull MVC, se concentre sur réutiliser le code via l'utilisation de widgets (components of view), de sorte que de nombreuses vues partagent le même code et ne personnalisent que leurs widgets. En ce qui concerne les contrôleurs, les pratiques courantes sont résumées et exécutées.
il s'agit de mélanger les MVC Pull et Push selon la nature et le rythme du logiciel.