2009-06-21 5 views
4

Actuellement, j'utilise le formidable Linq 2 Json.net (par newtonsoft), qui est un très bon outil simple pour générer des résultats JSON de manière programmatique.(Meilleure pratique) Comment mettre le résultat JSON dans ASP.net MVC Framework?

Mais après avoir terminé certains projets, j'ai arrêté et repensé, dois-je générer le résultat JSON dans le contrôleur? Je veux dire, dans .net MVC framework, il fournit un JSONResult comme l'un des ViewResult. Mais le contrôleur devrait-il déranger comment le résultat est généré? Ou devrait-il simplement "fournir" les données à voir, et le travail de la vue devrait générer le résultat nécessaire (et le formatage)? Une dernière chose, j'ai aussi entendu que l'utilisation de "ViewData" dans le contrôleur pourrait ne pas être une bonne idée car le contrôleur est trop préoccupant sur le problème d'affichage/sortie, un meilleur modèle ou méthode pourrait être utilisé?

Répondre

1

Je pense que je vais justifier la sortie JSON dans le contrôleur car JSON est juste une forme de ViewData, juste comme utiliser ViewData Dictionary pour communiquer avec les pages View.

Et la page View est déjà rendue, ou gérée par les langues côté client. Bien qu'un inconvénient est, le contrôleur de sortie JSON est assez dépendant de la vue, oui, vous pouvez toujours changer la vue à une autre chose qui accepte ce JSON comme canal de communication, mais pas une bonne idée si vous voulez changer le client à, par exemple, une application de bureau utilisant d'autres canaux comme la communication (comme la connexion TCP directe ou l'application SOAP etc.) parce que le contrôleur est fait pour JSON. (vrai, vous pouvez faire un adaptateur pour faire la traduction). Donc, pour terminer, le rendu JSON dans le contrôleur est OK tant que vous ne prévoyez pas d'autre plate-forme tout en présumant que le contrôleur reste inchangé.

0

Je règle généralement mes résultats pour JsonResults dans le contrôleur lui-même. Je sens qu'il appartient au Model/DAL/BLL de me donner les données/ienumerable filtrées comme demandé, mais le controller/view frob & le renvoie. Dans le cas d'un JsonResult, le framework gère la vue/l'encodage. Je réserverais des vues pour la sortie textuelle formatée (principalement html). Utilisez le gestionnaire/résultat intégré pour les réponses JSON et les fichiers/images. La sortie XML peut vraiment aller de toute façon.

+0

Je suis d'accord que les vues sont pour la sortie formatée, mais JSON n'est-ce pas un type de sortie de format? Il me semble que la sortie JSON pour le contrôleur fait vraiment deux choses, l'entrée de processus et la sortie de format en même temps. – xandy

1

La sortie JSON est assez simple avec la plupart des langages côté serveur, je n'ai jamais eu une raison (ou été en mesure de justifier des tentatives de) pour les compliquer avec des modèles.

Alors que vous le pouvez, le montant des frais généraux engagés est probablement une perte. Dans la plupart des cas, les modèles de rendu déclenchent un sous-système entier qui doit être liquidé avant même de se lancer en affaires. L'idée générale (pour moi) à propos de JSON (et des réponses AJAX en général) est que vous pouvez raser une tonne de frais généraux hors de votre serveur.

+0

Il s'agit d'une note spécifique à Rails ... Lors de la négociation de contenu, il est possible d'utiliser le langage de création de modèle pour créer des réponses JSON. En fin de compte, ces modèles sont simples. Je pense que cela s'appliquerait à tout autre langage où les modèles ont été utilisés pour générer une sortie JSON. –