3

Dies ist ein Beispiel, das ich hier gehoben haben: http://aspalliance.com/1776_ASPNET_MVC_Beta_Released.5Ausschließen Eigenschaften auf Modell Bindung Schnittstellen

public ActionResult Save(int id) 
{ 
Person person = GetPersonFromDatabase(id); 
try 
{ 
    UpdateMode<IPersonFormBindable>(person) 
    SavePersonToDatabase(person); 

    return RedirectToAction("Browse"); 
} 
catch 
{ 
    return View(person) 
} 
} 

interface IPersonFormBindable 
{ 
string Name {get; set;} 
int Age {get; set;} 
string Email {get; set;} 
} 

public class Person : IBindable 
{ 
public string Name {get; set;} 
public int Age {get; set;} 
public string Email {get; set;} 
public Decimal? Salary {get; set;} 
} 

Diese nicht Werte Eigenschaft Gehalt abbildet, sondern wird ausgeführt, dessen Validierung Attribute, die nicht zu erwarten ist, wenn Sie den Standard zu tun [Bind (ausschließen = "Gehalt")]

[Bind(Exclude="Salary")] 
public class Person 
{ 
public string Name {get; set;} 
public int Age {get; set;} 
public stiring Email {get; set;} 
public Decimal? Salary {get; set;} 
} 

Wie werde ich die [Bind (ausschließen = "Property")] implementieren diese Schnittstelle Muster verwendet?

+0

Wo ist die Frage? :) – Lorenzo

+0

Hi, ich dachte die Frage ist schon offensichtlich. Hier ist die Frage für Sie. –

Antwort

2

Hier ist, was ich Ihnen empfehlen würde: Verwenden Sie Ansichtsmodelle, und lassen Sie diese Schnittstellen fallen, verwirren Sie Ihre Controller nicht mit so viel Code. So brauchen Sie nicht das Gehalt in dieser speziellen Aktion gebunden zu sein: groß, verwenden ein speziell zugeschnittene Ansicht Modell zu dieser Ansicht:

public class PersonViewModel 
{ 
    public string Id { get; set; } 
    public string Name { get; set; } 
    public int Age { get; set; } 
    public string Email { get; set; } 
} 

Und Ihre Controller-Aktion:

public ActionResult Save(PersonViewModel person) 
{ 
    _repository.SavePersonToDatabase(person); 
    return RedirectToAction("Browse"); 

    // Notice how I've explicitly dropped the try/catch, 
    // you weren't doing anything meaningful with the exception anyways. 
    // I would simply leave the exception propagate. If there's 
    // a problem with the database it would be better to redirect 
    // the user to a 500.htm page telling him that something went wrong. 
} 

Wenn in einem anderen action Sie brauchten das Gehalt und schreiben dann ein anderes View-Modell für diese Ansicht. Machen Sie sich keine Sorgen, wenn Sie einige Eigenschaften zwischen Ihren Ansichtsmodellen wiederholen. Genau dafür sind sie bestimmt. Offensichtlich arbeitet Ihr Repository mit einem Modell und nicht mit einem Modell. Sie müssen also zwischen diesen beiden Typen mappen. Ich würde Ihnen empfehlen, AutoMapper für diesen Zweck zu verwenden.

Das ist mein Standpunkt: Schreiben Sie immer Ansichtsmodelle, die speziell auf die Bedürfnisse einer bestimmten Ansicht zugeschnitten sind. Versuchen Sie zu vermeiden, dass die Begriffe "Einschließen", "Ausschließen" oder "Eines Tages" beißen, jemand wird eine sensible Eigenschaft hinzufügen und wird vergessen, sie der Ausschlussliste hinzuzufügen. Und selbst wenn Sie Include verwenden, ist es immer noch hässlich.

+0

Wo platzieren Sie die Validierung? auf dem Viewmodel oder auf dem Domain-Modell? –

+1

@geocine, auf dem View-Modell, das ist, was der Controller von einer Ansicht empfängt, dies ist, was die Benutzereingabe darstellt, das ist, wo die erste Ebene der Validierung durchgeführt werden soll. Einfache Validierung wie erforderliche Eigenschaften, Datetime-Formate, ... Business-Validierung, z. B. ob ein Benutzer bereits im Datenspeicher vorhanden ist, sollte auf der Serviceebene durchgeführt werden, die eine zweite Validierungsebene darstellt. Hier werden die Geschäftsregeln validiert. –

Verwandte Themen