2009-07-18 7 views
1

Juste une question d'architecture: j'utilise ASP.net MVC et repose exclusivement sur des vues fortement typées avec des classes de modèles de vues.Code de formatage spécifique à l'affichage dans ASP.net MVC

Comme la présentation est le travail de la vue, ces classes ne contiennent pas seulement des champs, mais aussi des fonctions de formatage, par exemple,

// The ViewModel contains a List<Comment> which the view.aspx iterates 
// through, calling this function in a foreach-loop 
// PostingDateFormat and DesiredCulture are fields set by the controller, 
// and I don't know if they should be 
public string GetCommentDateLine(Comment c) 
{ 
    return c.CommentDate.ToString(this.PostingDateFormat, this.DesiredCulture); 
} 

Je me demande si cela est exact, ou si je dois déplacer c'est ailleurs? Cela est particulièrement préoccupant pour les fonctions utilisées par plusieurs vues. Devraient-ils vivre dans une classe spéciale en dehors de la hiérarchie? Ou être copié/collé (yikes) dans chaque classe de modèle de vue?

Ceci est également donné le fait que je pourrais avoir plusieurs vues sur le même ViewModel: Une vue normale pour les navigateurs, une autre vue pour les lecteurs RSS. Naturellement, le contrôleur ne doit peupler le viewmodel qu'avec des données, et la vue elle-même doit formater les données en fonction du support cible (par exemple, les dates dans les flux RSS sont formatées différemment des dates sur les sites Web normaux). Dois-je avoir ViewModels séparé pour Normal et RSS? Ou le contrôleur doit-il savoir que je veux un champ RSS et remplir le champ "PostingDateFormat" avec une valeur différente? Cela semble la meilleure solution (pas besoin de dupliquer les ViewModels pour chaque vue), mais je ne suis pas sûr si c'est le travail du contrôleur de savoir quel DateFormat la vue a besoin.

Répondre

2

Je suggère de mettre toute votre logique de formatage d'affichage dans les méthodes d'extension HtmlHelper. De cette façon vos viewmodels ne contiendront aucune logique de formatage et feront simplement ce qu'ils sont censés faire - transporter des objets du contrôleur à la vue.

Donc, dans votre cas, je suppose que vous voulez créer quelque chose comme:

namespace System.Web.Mvc 
{ 
    public static class HtmlExtensions 
    { 
     public static string CommentDateLine(this HtmlHelper html, 
              Comment comment, 
              string format, 
              IFormatProvider formatProvider) 
     { 
      return comment.CommentDate.ToString(format, formatProvider); 
     } 
    } 
} 

En ce qui concerne la question de PostingDateFormat, comme vous faites allusion, je retournerais très certainement pas créer ViewModels séparés pour chaque vue. Vous pouvez créer une méthode d'extension distincte pour le formatage de la date RSS (ce qui éliminerait peut-être le besoin de l'ensemble PostingDateFormat dans le ViewModel?).

HTHS,
Charles

+0

Juste pour ajouter à ceci: j'ai mis le format réel fournisseur et Format de date dans le web.config et y accéder par un centre paramètres de classe. De cette façon, le Helt Html ne fait que le formater, mais n'est pas concerné par le format réel. http://www.stum.de/2009/12/28/having-a-nested-configuration-section-in-web-config/ –