ASP.NET MVC - Modèle de liaison Personnalisé sur le Type d'Interface

Je ne sais pas si ce comportement est normal ou pas, mais il semble que la coutume de la liaison de modèle ne fonctionne pas lorsque la liaison est affecté à un type d'interface. Quelqu'un a expérimenté ce?

public interface ISomeModel {}
public class SomeModel : ISomeModel {}

public class MvcApplication : HttpApplication {
    protected void Application_Start(object sender, EventArgs e) {
        ModelBinders.Binders[typeof(ISomeModel)] = new MyCustomModelBinder();
    }
}

Avec le code ci-dessus lorsque je lier à un modèle de type SomeModel, MyCustomModelBinder n'est jamais atteint; cependant, si je change le code ci-dessus et remplacer typeof(ISomeModel) pour typeof(SomeModel) et post exactement la même forme MyCustomModelBinder est appelé comme prévu. Est-ce que semblent droit?

Modifier

Je me suis retrouvé dans cette situation plus d'un an après j'ai d'abord posé cette question, et maintenant j'ai une solution qui fonctionne. Merci Matt Hidinger!

http://www.matthidinger.com/archive/2011/08/16/An-inheritance-aware-ModelBinderProvider-in-MVC-3.aspx

InformationsquelleAutor Nathan Taylor | 2010-06-04
  1. 5

    Je ne suis pas sûr si son directement liés, mais oui il y a des choses que vous devez penser lors de l'utilisation de la liaison de modèle et interfaces... j'ai couru dans des problèmes similaires avec le modèle de classeur par défaut, mais il peut ne pas être directement liée, selon la façon dont vous faites les choses...

    Ont un oeil à ce qui suit:
    ASP.net MVC v2 - Débogage du Modèle de Problèmes de Liaison - BUG?
    ASP.net MVC v2 - Débogage du Modèle de Problèmes de Liaison - correction d'un BUG?

    • Mon héritage de la structure est un peu différente de la vôtre, mais il ne semble pas que cela peut être un problème connexe. Je pense que le modèle de système de liaison pourrait en déduire qu'un type qui implémente une interface doit être soumis au modèle de classeur affectées à cette interface, tant qu'il n'est pas un autre type de liaison à un plus concrète du type de l'interface (même classe, ou de la classe de base). Je suppose que je peux voir pourquoi ce serait une zone grise.
    • C'était mon sentiment trop... je m'attendais juste à travailler, mais il s'avère que lorsque l'on travaille avec des interfaces de cette façon, en général avec asp.net MVC (même si ses pas strictement un MVC limitation elles pourraient permettre s'ils le voulaient) vous allez probablement rencontrer des problèmes/comportement inattendu si vous n'êtes pas en pensant à ces problèmes d'interface... par conséquent, la zone grise...
    InformationsquelleAutor anthonyv
  2. 10

    Je faisais des expériences avec ce problème et je suis venu avec une solution de tris. J'ai fait une classe appelée InterfaceModelBinder:

    public class InterfaceModelBinder : DefaultModelBinder
{
    public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)
    {
        ModelBindingContext context = new ModelBindingContext(bindingContext);
        var item = Activator.CreateInstance(
            Type.GetType(controllerContext.RequestContext.HttpContext.Request.Form["AssemblyQualifiedName"]));

        Func<object> modelAccessor = () => item;
        context.ModelMetadata = new ModelMetadata(new DataAnnotationsModelMetadataProvider(),
            bindingContext.ModelMetadata.ContainerType, modelAccessor, item.GetType(), bindingContext.ModelName);

        return base.BindModel(controllerContext, context);
    }
}

    Qui j'ai enregistré dans mon Application_Start de la manière suivante:

    ModelBinders.Binders.Add(typeof(IFormSubmission), new InterfaceModelBinder.Models.InterfaceModelBinder());

    L'interface et une implémentation concrète ressembler à ceci:

    public interface IFormSubmission
{
}

public class ContactForm : IFormSubmission
{
    public string Name
    {
        get;
        set;
    }

    public string Email
    {
        get;
        set;
    }

    public string Comments
    {
        get;
        set;
    }
}

    Le seul inconvénient de cette approche dans son ensemble (comme vous l'avez recueilli déjà), c'est que j'ai besoin d'obtenir le AssemblyQualifiedName de quelque part, et dans cet exemple, elle est stockée comme un champ caché sur le côté client, comme suit:

    <%=Html.HiddenFor(m => m.GetType().AssemblyQualifiedName) %>

    Je ne suis pas certain cependant que les inconvénients d'exposer le Type de nom pour le client sont à la peine de perdre les avantages de cette approche. Une Action de ce genre peut gérer tous mes envois de formulaire:

    [HttpPost]
public ActionResult Process(IFormSubmission form)
{
    if (ModelState.IsValid)
    {
        FormManager manager = new FormManager();
        manager.Process(form);
    }

    //do whatever you want
}

    Toute réflexion sur cette approche?

    • Semble que ce serait faire le tour, mais comme vous l'avez dit, le nom de l'assembly dans votre type semble que vous devriez être avoir des ennuis. Je ne suis pas actuellement un bon cas d'utilisation de la façon dont il pourrait être utilisé à des fins malveillantes, mais ça sent drôle pour moi.
    • Peut-être une solution à ce problème serait de hachage ou le chiffrement du type de nom sur le client, et ensuite faire sence que dans le modèle de classeur.
    InformationsquelleAutor Nathan Anderson