Déplacement d'instructions conditionnelles complexes vers un code derrière

Question

Je me demandais si, en déplaçant des instructions complexes si else et le balisage HTML résultant vers le code derrière, violait une loi 'MVC'?

Cela semble être une excellente option face à des déclarations en ligne qui pourraient devenir extrêmement illisibles.

Answer 1

Je préfère ne pas utiliser le code derrière la classe dans mes vues. Ce n’est pas parce qu’il viole MVC par défaut, mais parce que j’ai trouvé que le & "Naturel &"; façon (au moins pour moi) est différent.

Lorsque je suis confronté à un balisage HTML complexe lié à de simples préoccupations d'affichage, j'écris généralement une méthode d'extension pour la classe HtmlHelper afin de masquer la complexité. Ainsi, j'ai des extensions comme Html.MoneyTextBox(), Html.OptionGroup() et Html.Pager<T>.

Dans d’autres cas, lorsque des conditions complexes se présentent, j’ai manqué quelque chose du contrôleur. Par exemple, tous les problèmes liés à la visibilité, à la lecture seule ou à l'activation d'éléments proviennent généralement de quelque chose que le contrôleur peut fournir. Dans ce cas, au lieu de transmettre le modèle à la vue, je crée un modèle de vue qui encapsule le modèle et les informations supplémentaires que le contrôleur peut fournir afin de simplifier le balisage HTML. Voici un exemple typique de modèle de vue:

public class CustomerInfo
{
  public Customer Customer { get; set; }
  public bool IsEditable { get; set; }  // e.g. based on current user/role
  public bool NeedFullAddress { get; set; }  // e.g. based on requested action 
  public bool IsEligibleForSomething { get; set; }  // e.g. based on business rule
} 

Cela dit, le code derrière fait partie de la vue. Vous pouvez donc l'utiliser librement, s'il répond mieux à vos besoins.

Answer 2

Ce n’est pas horrible d’avoir des conditionnels à votre avis. Je les garderais dans l'ASPX pas le code derrière. Cependant, un conditionnel indique souvent un comportement de contrôle. Considérez le code ASPX suivant:

<%if (ViewData["something"] == "foo") {%>
     <%=Html.ActionLink("Save", "Save") %> 
<%}%>
<%if (ViewData["somethingElse"] == "bar") {%>
     <%=Html.ActionLink("Delete", "Delete") %> 
<%}%>

Cet ensemble de conditions représente le comportement de contrôle géré par la vue, c'est-à-dire au mauvais endroit. Ce comportement n'est pas testable par unité. Considérons plutôt:

<%foreach (var command in (IList<ICommand>)ViewData["commands"]) {%>
     <%=Html.ActionLink(command) %>
<%}%>

Dans cet exemple, ActionLink est une extension personnalisée de HtmlHelper qui prend notre propre objet de spécification ICommand. L'action du contrôleur qui rend cette vue remplit ViewData [& Quot; commandes & ";] En fonction de diverses conditions. En d'autres termes, le contrôleur effectue le contrôle. Dans les tests unitaires de cette action, nous pouvons vérifier que le bon ensemble de commandes sera présenté dans diverses conditions.

Au début, cela peut sembler un problème comparé à la projection rapide de quelques FI dans la vue. La question que vous devez vous poser est la suivante: & "Ce SI représente-t-il un comportement dominant et est-ce que je veux m'assurer que rien ne se cassera à un moment donné? &";

Answer 3

Je crois que tant qu'il s'agit d'un code de rendu et que celui-ci se trouve dans un " View " pas dans un contrôleur, alors le mettre sur le code derrière ou en ligne n'aura pas d'importance. Assurez-vous simplement que vous n'écrivez pas cette partie du code de rendu dans les actions de Contrôleurs (de cette manière, vous violerez vraiment le modèle MVC).

Answer 4

Le codebehind fait partie de la vue - à vous de choisir si vous souhaitez placer des éléments dans l’ASPX directement ou dans le code arrière. MVC ne signifie pas que vous devez coder tout ce qui est laid dans l’ASPX:).