Question

J'ai lu à travers quelques questions sur les articles ici et divers sur MVC et peut voir comment il peut même être appliquée à l'événement GUI applications intensives comme une application de peinture.

Quelqu'un peut-il citer une situation où MVC pourrait être une mauvaise chose et son utilisation malavisée?

EDIT: Je parle en particulier sur les applications de l'interface graphique ici

Était-ce utile?

La solution

J'ai essayé MVC dans mon pilote du noyau de réseau. Le patch a été rejeté.

Autres conseils

Je pense que vous regardez ce genre d'arrière. Le point est de ne pas voir où vous pouvez appliquer un modèle comme MVC, le point est d'apprendre les motifs et reconnaître quand le problème que vous essayez de résoudre peut naturellement être résolu en appliquant le modèle. Donc, si votre espace de problème peut être naturellement divisé en modèle, vue et le contrôleur alors il est un bon candidat pour MVC. Si vous ne pouvez pas voir facilement quelles parties de votre chute de conception dans les trois catégories, il ne peut pas être le modèle approprié.

MVC est logique pour les applications web. Dans les applications Web, vous traitez des données (sur SA: rédaction des questions, en ajoutant des commentaires, en changeant les informations de l'utilisateur), vous avez l'état (utilisateur connecté), vous n'avez pas beaucoup de pages différentes, mais beaucoup de contenu différent pour entrer dans ces pages. Une page de questions par rapport à un million de questions.

Pour faire CMS, par exemple, MVC est inutile. Vous n'avez pas des modèles, pas de contrôleurs, seulement des pages de texte avec des décorations et des menus. Le problème est pas de traitement plus de données -. Le problème est maintenant au service que le contenu du texte correctement

Tho, CMS Admin construirait sur le dessus de MVC très bien, il est juste partie utilisateur qui ne serait pas.

Pour les services Web, vous feriez mieux d'utiliser REST qui, je crois, est un paradigme distinct.

application WebDAV ne bénéficierait grandement de MVC, soit.

La mise en garde sur Ruby pour la programmation Web est que Rails est mieux adapté pour la construction Des applications Web. Je l'ai vu essayer de nombreux projets pour créer un serveur WebDAV ou un système de gestion de contenu CMS avec Rails et échouent lamentablement. Alors que vous pouvez faire un CMS dans Rails, il existe des technologies beaucoup plus efficaces pour la tâche, comme Drupal et Django. En fait, je dirais que si vous cherchez à un effort de développement du portail Java, vous devez évaluer Drupal et Django pour la tâche à la place.

Tout où vous voulez déposer dans les composants 3ème partie, il sera difficile de travailler dans le modèle MVC. Un bon exemple de ceci est un CMS.

Chaque composant que vous obtenez aura leurs objets de contrôleur « propres » et vous ne serez pas en mesure de partager le « contrôle » du modèle -> passant ui.

Je ne sais pas nécessairement que MVC est jamais vraiment un mauvaise idée pour une application GUI. Mais il existe des alternatives qui sont sans doute mieux (et sans doute pire en fonction de l'opinion dont vous demandez). La plus courante est MVP. Voir ici pour une explication: Tout ce que vous avez voulu savoir sur MVC et MVP Mais oser le demander .

Bien que je suppose que ce serait peut-être une mauvaise idée d'utiliser MVC si vous utilisez un cadre ou d'interagir autrement avec un logiciel qui n'a pas été conçu avec MVC à l'esprit.

En d'autres termes, il est un peu comme comparer des langages de programmation. Il n'y a généralement pas beaucoup de tâches que l'on peut dire que l'un est meilleur que l'autre pour. Elle se résume généralement à la préférence programmeur, la disponibilité des bibliothèques, et l'expérience de l'équipe.

MVC ne doit pas être utilisé dans des applications où la performance est critique. Je ne sais pas si cela applys encore avec l'augmentation de la puissance de calcul, mais un exemple est une application de centre d'appels. Si vous pouvez enregistrer .5 secondes par appel entrant et l'information mise à jour de ces économies additionnent au fil du temps. Pour obtenir le dernier morceau de la performance de votre application, vous devez utiliser une application de bureau au lieu d'une application web et l'ont parler directement à la base de données.

Quand est-ce une mauvaise chose? Partout où il y a un autre code structure qui permettrait de mieux adapter à votre projet.

Il y a d'innombrables projets dans lesquels MVC ne serait pas « adapter », mais je ne vois pas comment une liste d'entre eux serait un avantage ..

Si MVC convient, utilisez, sinon, utilisez autre chose ..

MVC et ORM sont une blague .... ils ne sont appropriés que lorsque votre application n'est pas une application de base de données, ou lorsque vous souhaitez conserver la base de données de l'application agnostique. Si vous utilisez un SGBDR qui prend en charge les procédures stockées, alors c'est la seule façon d'aller. procs stockées sont l'approche préférée pour les développeurs d'applications expérimentés. MVC et ORM ne sont promus par les entreprises qui tentent de vendre des produits ou des services liés à ces technologies (par exemple Microsoft pour essayer de vendre VS). Arrêtez de perdre votre temps à apprendre Java et C #, se concentrer plutôt sur ce qui compte vraiment, Javascript et SQL.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top