ASP.NET MVC: Combien de traitement dans la vue et quand utiliser les méthodes auxiliaires?

Question

Ma vue ASP.NET MVC devient "encombrée" parce que souvent j'ai besoin de montrer conditionnellement ce qui conduit à un code C# long, y compris des instructions opérateur ternaires difficiles à lire (exemples de démonstration) et des constructions similaires.

<%= Model.SupportsFeature ? Model.HasName ? "This model supports the feature and has a name" : "This model supports the feature and has no name" : "This model doesn't support the feature" %> 

Maintenant, dois-je garder cette logique (toujours vue liée) dans la vue, ou devrais-je plutôt:

1) Ecrire un HtmlHelper GetSupportedText (cette ... Méthode d'extension

?

2) Écrire une méthode d'extension à la classe Modèle réelle? J'essaie de garder mon code concis et de garder les choses liées ensemble, mais je ne sais vraiment pas comment structurer cela et gérer les vues qui deviennent encombrées avec <%%>.

Merci pour vos commentaires à ce sujet!

EDIT: Je suis également préoccupé par la mise en HTML à partir d'une méthode d'aide C# (sous forme de chaîne) - qui est difficile à déboguer un vraiment laid.

Answer 1

Vous pouvez utiliser la classe TagBuilder pour créer des chaînes HTML si vous le préférez via String.Format() ou une concaténation de chaîne. J'ai aussi utilisé les classes System.Xml.Linq pour du HTML très compliqué.

La règle générale que je suis est: "S'il y a un si, écrivez une aide HTML." Je ne peux pas réclamer crédit pour cette déclaration, mais je ne me souviens pas où je l'ai entendu. Cette règle va provoquer une explosion des extensions d'aide HTML, donc j'organise mes extensions avec des espaces de noms. Je crée un espace de nom d'extension partagé entre les vues que j'ajoute à web.config, puis je crée des fichiers de code d'extension et des espaces de noms spécifiques à la vue que j'utilise pour chaque vue spécifique. Cela rend beaucoup plus facile de trouver où résident vos extensions si vous organisez votre code d'une manière logique et vous n'aurez pas une quantité énorme d'assistants inutiles qui encombrent votre objet HTML là où ils ne sont pas nécessaires.

Voici un exemple, utilisant le nom d'application par défaut MvcApplication1.

Ajouté à web.config d'inclure mes aides partagées dans toutes les vues:

<pages> 
    <namespaces> 
    <add namespace="MvcApplication1.Helpers.Shared"/> 
    </namespaces> 
</pages> 

Ceci est un exemple simplifié et instrumentale de mes aides spécifiques à la vue pour la maison/About.aspx.

namespace MvcApplication1.Helpers.About 
{ 
    public static class AboutViewExtensions 
    { 
     public static string AboutViewHelper(this HtmlHelper Html) 
     { 
      var tb = new TagBuilder("b"); 
      tb.SetInnerText("bold text"); 
      return tb.ToString(TagRenderMode.Normal); 
     } 
    } 
} 

est ici le point de vue About.aspx en utilisant la directive <%@ Import %> pour apporter dans mon espace de noms.

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %> 
<%@ Import Namespace="MvcApplication1.Helpers.About" %> 

<asp:Content ID="aboutContent" ContentPlaceHolderID="MainContent" runat="server"> 
    <h2>About</h2> 
    <p> 
     <%= Html.AboutViewHelper() %> 
    </p> 
</asp:Content> 

Answer 2

Si vous utilisez une approche ViewModel, vous pouvez coller cette logique dans une méthode/getter dans votre ViewModel.

Answer 3

Ceci entrerait dans une classe Helper - de préférence en tant que méthode d'extension. Là, vous pouvez également appliquer la localisation (si nécessaire).

L'autre alternative consiste à créer une nouvelle propriété (utiliser une classe partagée si celle-ci est générée par Linq to Sql) qui le fait pour vous (génère un message conditionnel). De cette façon, vous pouvez utiliser la propriété avec d'autres sorties (comme JSON, etc.).

Bottom line - faire ce qui fonctionne. Vous avez raison de supprimer les éléments conditionnels de la vue - trop difficile à déboguer. Si vous le lancez sur le modèle, vous pouvez le tester aussi :)