ASP.Net MVC Postback et modèles

C'est surtout une suite à un commentaire de cette délivrance, mais je n'ai pas assez de réputation pour le commentaire ...

ASP.Net MVC Publication d'une étiquette de la valeur à votre contrôleur

Disons que j'ai un modèle simple:

public class SimpleClass
{
    public String Label { get; set; }
    public String FirstName { get; set; }
}

Étiquette est modifiée en fonction de l'utilisateur/du client de sorte qu'il ne peut pas être un DataAttribute. Si lors de la comptabilisation de traitement des problèmes se produisent, nous devons refaire l'intégralité de la page. C'est le noeud du problème du post précédent. La solution retenue est de faire ceci:

@Html.DisplayTextFor(model => model.Label)
@Html.HiddenFor(model => model.Label)
@Html.EditorFor(model => model.FirstName)

Qui fait sens en ce qu'elle fonctionne. Mais nos modèles sont beaucoup plus complexes et plus vastes. Cette méthode entraînera une tonne de champs cachés, ce qui semble être un très sale solution.

Ce qui m'amène à JP commentaire:

ASP.Net MVC Publication d'une étiquette de la valeur à votre contrôleur

La seule solution est de recharger le modèle. Mais ce n'est pas seulement un reload, c'est aussi une fusion puisque vous voulez conserver toutes les données côté client changements.

default: SimpleClass { Label="TheLabel", FirstName="Rob"}
postedback: SimpleClass { Label="", FirstName="Steve" }
we want: SimpleClass { Label="TheLabel", "FirstName="Steve" }

Ma question est: MVC ont un bon moyen de savoir quels champs ont été postedback de sorte qu'il fusionne correctement? Nous devons seulement de fusion postedback des champs n'est pas vide propriétés.

Ou est-il préférable de simplement ajaxify l'ensemble de la publication et de ne pas faire la soumission d'un formulaire? Cela évite tous les modèle de recharger les questions sur "soumettre".

Mise à jour

Pour donner Pablo de crédit j'ai accepté cette solution. Voir mon exemple simple de sa solution, vérifier Robert Harvey commentaire dans les Réponses ci-dessous:

ASP.Net MVC Publication et Modèles

source d'informationauteur Rob

asp.net-mvc c#model-binding

5

Le principal problème ici est de tenter d'adapter les WebForms' Publication concepts de la MVC. Il n'y a pas une telle chose comme une dynamique de publication où les choses sont automatiquement conservent leur état.

Vous n'avez Viewmodel qui sont liés à la vue, et Viewmodel qui sont validées par la vue du Contrôleur. Ils n'ont même pas forcément besoin d'être du même Type. Sens, le contrôleur ne doit recevoir les données que l'utilisateur peut en effet changer, pas de grands objets avec beaucoup de propriétés qui faisaient partie de la première ViewModel mais sont en lecture seule.

Étiquettes couramment représentent en lecture seulement les textes et qu'ils ne sont pas modifiables, les éléments de formulaire. Qui est pourquoi vous devez utiliser les champs cachés.

Et oui, parfois, cela implique que vous devez recharger les données d'origine dans le contrôleur, et sync avec les nouvelles données que vous avez posté, ce qui n'est pas nécessairement une mauvaise chose. Si vous liez des données en lecture seule à vue, dont l'utilisateur ne peut pas modifier manuellement, vous ne devriez pas vraiment la confiance que les données de retour dans un poste par la suite. Juste parce que votre code html peut essayer de le faire en lecture seule ne signifie pas que je ne peut pas manipuler la poste et en fin de compte changer votre "lecture seule" des données, sans le savoir.

Je viens de lire la deuxième question que vous avez mentionné, et apparemment, son principal problème était qu'il était à essayer de réutiliser le même ViewModel de nouveau, de sorte que toutes les données étaient manquantes et le modèle n'était pas valide. La solution qui est en fait très simple, SEULEMENT après ce que vous avez besoin, comme une nouvelle ViewModel et le contrôleur de prendre soin de tout le reste.

[Déplacé de l'OP]

Je pense que c'est ce que Pablo est ce qui suggère pour ceux qui se demandent. Il semble être un bon modèle pour résoudre ce problème.

Modèles:

    public class SimpleClass : SimpleClassPostBack
    {
        public String Label { get; set; }

        public SimpleClass()
        {
            //simulate default loading
            Label = "My Label";
            FirstName = "Rob";
        }

    }

    //contains only editable by the user fields
    public class SimpleClassPostBack
    {
        public String FirstName { get; set; }
    }

Des Actions De Contrôleur:

    [HttpGet]
    public ActionResult SimpleClassExample3()
    {
        SimpleClass simpleClass = new SimpleClass();
        return View(simpleClass);
    }

    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult SimpleClassExample3(SimpleClassPostBack postBackSimpleClass)
    {
        Boolean errorOccurred = true;

        if (!errorOccurred)
        {
            //do whatever success action is necessary
        }

        //redraw the page, an error occurred

        //reload the original model
        SimpleClass simpleClass = new SimpleClass();

        //move the posted back data into the model
        //can use fancy reflection to automate this
        simpleClass.FirstName = postBackSimpleClass.FirstName;

        //bind the view
        return View(simpleClass);
    }

Vue:

@model SimpleClass

@{
    ViewBag.Title = "Simple Class Example3";
}

<h2>Simple Class Example3</h2>

@using (Html.BeginForm())
{
    @Html.AntiForgeryToken()

    <label for="FirstName">@Html.DisplayFor(m => m.Label)</label>
    @Html.EditorFor(m => m.FirstName)

    <br/>

    <button>Submit</button>

}

2

Vous ne devez envoyer des données du client vers le serveur que le serveur ne peut pas "comprendre" sur son propre. Si le serveur ne sait ce que les étiquettes ont été lorsque l'utilisateur navigue d'abord de ce point de vue, puis si l'utilisateur ne peut pas modifier, le serveur sera en mesure de savoir ce que les étiquettes sont lors du rechargement de la vue.

Utiliser les champs cachés à identifier les objets de base de données. Si votre SimpleClass devrait probablement avoir une sorte de Id que vous allez utiliser dans le secret d'entrée. Utiliser le EditorFor pour FirstName. Maintenant, lorsque le formulaire est affiché, utilisez les envoyés Id pour trouver la bonne SimpleClass à partir de la base de données et de modifier son FirstName propriété avec la valeur affichée. Le Label propriété sera null ce qui est normal puisque vous n'avez pas besoin de l'enregistrer. Maintenant, si il y a un problème dans le poste et que vous voulez envoyer le même point de vue, comme il a été, vous avez besoin de repeupler le Label de la même manière que lorsque l'utilisateur est arrivé à la vue pour la première fois. Les valeurs de Id et FirstName propriétés sera automatiquement renvoyé à la vue avec le modèle de l'état.

En résumé:
- Affichez uniquement les données nécessaires pour identifier quelque chose et ce que l'utilisateur
  pouvez modifier ce point de vue.
- Ne vous fiez pas au client de vous envoyer quelque chose de valable. L'utilisateur peut modifier les valeurs du champ caché étiquettes à rien.

Vous devez vous connecter pour publier un commentaire.