Wenn Daten Anmerkungen mit MVC, Pro und Contra einer Schnittstelle im Vergleich zu einem MetadataType

Question

mit der Wenn Sie this article on Validation with the Data Annotation Validators lesen, zeigt es, dass Sie das MetadataType Attribut verwenden können Validierungsattribute Eigenschaften auf Teilklassen hinzuzufügen. Sie verwenden dies, wenn Sie mit ORMs wie LINQ to SQL, Entity Framework oder Subsonic arbeiten. Dann können Sie die "automagische" Client- und Serverseitige Validierung verwenden. Es spielt sehr gut mit MVC.

Allerdings verwendete ein Kollege von mir eine Schnittstelle, um genau das gleiche Ergebnis zu erzielen. es sieht fast genau gleich aus und erfüllt funktional dasselbe. Anstatt also, dies zu tun:

[MetadataType(typeof(MovieMetaData))] 
public partial class Movie 
{ 
} 

public class MovieMetaData 
{ 
    [Required] 
    public object Title { get; set; } 

    [Required] 
    [StringLength(5)] 
    public object Director { get; set; } 


    [DisplayName("Date Released")] 
    [Required] 
    public object DateReleased { get; set; } 
} 

Er tat dies:

public partial class Movie :IMovie 
{ 
} 

public interface IMovie 
{ 
    [Required] 
    object Title { get; set; } 

    [Required] 
    [StringLength(5)] 
    object Director { get; set; } 


    [DisplayName("Date Released")] 
    [Required] 
    object DateReleased { get; set; } 
} 

Also meine Frage ist, wann ist dieser Unterschied tatsächlich eine Rolle?

Meine Gedanken sind, dass Interfaces eher "wiederverwendbar" sind, und dass es für einen einzelnen Kurs keinen Sinn macht, ihn zu machen. Sie könnten auch argumentieren, dass Sie Ihre Klassen und Interfaces so gestalten können, dass Sie Interfaces für mehrere Objekte verwenden können, aber ich habe das Gefühl, dass Ihre Modelle in etwas anderes passen, wenn sie wirklich alleine stehen sollten. Was denken Sie?

Answer 1

Ich mag Ihren Schnittstellenansatz, da Sie einen Vertrag für Ihr Modell definieren können, mit dem Sie Ihre ORM-generierten Klassen anpassen können. Dadurch können Sie Ihre App vom ORM-Framework entkoppeln und die MetadataType-Schnittstelle besser ausnutzen, da sie als Metadaten für die Datenvalidierung sowie als Vertrag für Ihr Modell dient. Sie könnten Ihre Schnittstelle auch mit Serialisierungsattributen dekorieren, damit WCF mehr aus der Schnittstelle herausholen kann. Ich habe ein paar frühe Blogs verfolgt, die die Erstellung eines Metadaten-Kurses empfohlen haben, aber ich denke, dass die Interface-Lösung eine gute Idee ist.

Answer 2

Ich sehe keinen funktionalen Unterschied zwischen den beiden Ansätzen. Ich bin mir nicht sicher, ob die Wiederverwendbarkeit wirklich wichtig ist, da die Validierung meistens auf "einmaligen" ViewModels erfolgt, die wahrscheinlich nicht viel, wenn überhaupt, wiederverwenden werden.

Answer 3

Wenn diese zwei Optionen sind die beiden, die ich vorgestellt werde, würde ich persönlich wahrscheinlich die Schnittstelle Weg wählen, einfach weil ich denke, es sieht sauberer. Aber das basiert ausschließlich auf dem persönlichen Geschmack - ich weiß nicht genug über die inneren Abläufe von .NET, um es mit Sicherheit zu sagen, aber ich kenne keinen Fall, in dem die tatsächliche Funktionalität der beiden Ansätze unterschiedlich wäre.

Auf der anderen Seite wäre ein wesentlich besserer Ansatz, Datenübertragungsobjekte (Data Transfer Objects, DTOs) zum Senden von Daten hin und her zu verwenden, und die Validierungsanforderungen für sie zu haben. Das heißt, anstatt dass das Movie Objekt alle Validierungsanforderungen erfüllen muss, müssen Sie ein MovieInput Objekt, das alle diese Anforderungen erfüllt, und dann Code erstellen, um eine korrekte MovieInput in eine Movie zu mappen. (Wenn Sie das nicht manuell machen möchten, können Sie AutoMapper oder ein anderes Dienstprogramm verwenden).

Das Konzept ist im Grunde aus so etwas wie ein Blick Model-Objekt auf dem Weg in genauso gut wie auf dem Weg zu haben - ich habe nur könnte auch lassen MovieInputMovieViewModel und es nannte verwendet für die Übertragung von Daten sowohl innerhalb als auch außerhalb des Servers.