Je suis confus entre la logique de domaine / application et la logique d'interface utilisateur. Pour illustrer ce que j'essaie de clouer, je vais décrire un programme imaginaire ci-dessous à des fins d'illustration:
(1) Imaginez une petite application avec un ensemble de 3 dérivations en cascade. Comme vous sélectionnez une liste déroulante, il déclenche une get d'ajax JQuery, qui finit par frapper un contrôleur MVC, fournissant la valeur sélectionnée de la liste déroulante précédemment sélectionnée. Le contrôleur renvoie les choix autorisés pour la prochaine liste déroulante. Le javacript (dans la vue) organise ces résultats dans une liste déroulante. etc. Donc, chaque fois que vous sélectionnez une liste déroulante, le prochain est peuplé.
(2) Maintenant, jetant dans une clé. Il y a quelques exceptions près. Disons que si l'utilisateur sélectionne "FOO" ou "BAR" dans la première liste déroulante, alors le BÉLAVORY change, de sorte que la deuxième liste déroulante soit désactivée et que la liste déroulante du THRID affiche une texbox à la place.
Mes questions est, dans le contexte de MVC, quel est le lieu approprié pour cette "décision"? Comme le code qui est responsable de la prise de ces décisions comme je l'ai expliqué dans (2). L'endroit le plus pratique que j'ai mis cela était juste dans le JavaScript de la vue. J'ai simplement écrit JavaScript pour tester si la première case est "FOO" ou "Barre", puis désactivez la seconde Dropwdown et échangeez la troisième liste déroulante pour une zone de texte. Mais cela ne se sent pas parfaitement juste pour moi. Parce qu'il semble que cela devrait être une logique commerciale, le code devrait appartenir à une couche de domaine quelque place. Mais cela ne se sent pas tout à fait raison non plus.
Et donc j'ai l'impression d'aller dans des cercles. Quelqu'un peut-il verser une lumière sur ce petit design?
4 Réponses :
Dans cette situation où vous avez des actions très spécialisées, vous devez le mettre dans la logique dans le JS comme vous l'avez fait dans votre exemple. Vous voudrez également toujours mettre la validation sur le côté serveur également pour que vos données soient propres.
Avec les trucs de MVC 2 sortant, ils ont une très grande validation du serveur de validation / une validation du côté client. Découvrez la publication de Scott Gu par Scott Gu sur ceci: MVC 2 Blog Post
sans diviser trop de poils ou devenir trop fanatique sur ce qui doit être fait pour garder le modèle pur ...
Évidemment, le contrôleur sait que ce changement doit se produire, car il traitera des cas de résultat résultant (sélections de dépose ou entrée de texte). Donc, mettre la logique relatif à cela dans le contrôleur est pas un péché.
Il est également aussi évident que la vue doit modifier la manière dont il affiche en fonction du contenu de la première liste déroulante. Bien que ce mélange de comportements ne soit pas exactement la meilleure expérience d'interface utilisateur que je puisse imaginer, si les exigences doivent, alors la logique doit exister dans une certaine mesure dans l'interface utilisateur. Mais, jeez les gars, c'est un site nous parlons ici. Voulez-vous vraiment supprimer toute la logique de JavaScript et déplacez-la dans une méthode du contrôleur? La vue est en train de décider comment afficher les données, qui est son travail, et donc ne peut pas être un péché .
La voie réelle d'éviter d'être brûlées à l'enjeu est de repenser pour éviter la controverse en premier lieu. Ou, il suffit de coder et de chier sur vos exigences de conception moche sur une bière.
Commençons par le modèle de domaine. Un modèle de domaine est une API les modèles du domaine de la technologie neutre de la technologie. Cela ne connaît rien sur les technologies d'affichage tels que JQuery, HTML ou (pour cette affaire) XAML ou Formulaires Windows.
Le modèle de domaine contient des classes et des interfaces décrivant le domaine et vous permet de modéliser les concepts de domaine de manière riche et expressif - quel que soit le type d'application que vous développez.
Avec cela à l'esprit, il est assez facile de voir que la logique d'affichage que vous décrivez n'appartient pas au modèle de domaine. Il doit donc appartenir à une couche spécifique à l'UI.
Vous pouvez mettre cela dans un module Logic distinct ou avec votre application UI - dans votre cas une application ASP.NET MVC. Si vous exprimez la logique UI souhaitée dans JavaScript ou le côté serveur est moins importante.
Personnellement, je définirais ce côté serveur logique dans des vues partielles, mais c'est parce que je me soucie beaucoup de testabilité, et je sais comment je voudrais tester un tel comportement (on m'a dit qu'il est possible de tester le code JQuery. De plus, mais je n'ai aucune idée de savoir si c'est vrai ou non).
Si jamais vous finissez par écrire une autre application basée sur le même modèle de domaine, il est très probable que la logique d'affichage s'avère très différente, car différentes technologies impliquent différents paradigmes.
Compte tenu de votre exemple, cela ne me dérangerait pas cette logique dans le contrôleur, cela n'appartient certainement pas au modèle de domaine. Je me sentirais personnellement mieux attraper la demande d'Ajax obtenir dans le contrôleur et décider de quoi générer de là avec Json au lieu de faire toute cette logique dans JQuery (je me sens juste plus à l'aise en C # puis dans JavaScript). Avec cet étant dit, j'aime garder mes méthodes d'action maigres alors ce que je ferais est de placer la logique impliquée dans la détermination de ce pour remplir les dépositions dans une méthode du conroller et le décorer avec [Nonaction].
Dieu comment cette question me plaint dans mon temps d'arrêt.