2010-12-14 9 views
2

In meiner Datenbank habe ich 40 Tabellen, die nur eine ID-Nummer und einen Namen enthalten. Auf meine Datenbank wird mit Entity Framework zugegriffen. Während ich keine Probleme habe, sie jeweils zu bearbeiten, indem ich für jedes Objekt eine stark typisierte Ansichts- und Postback-Methode erzeuge, möchte ich eine allgemeinere Methode und Ansicht zum Betrachten und Bearbeiten dieser Objekte erstellen.Erstellen einer allgemeinen Bearbeitungsansicht mit ASP.NET, MVC und Entity Framework

Ich verwende derzeit den folgenden Code, um auf jedes Objekt zuzugreifen. In diesem Fall ist es für ein Objekt von ‚Address‘:

public ActionMethod EditAddressType(int ID) 
{ 
    var result = database.AddressType.Single(a => a.ID == ID); 
    View(result); 
} 

[HttpPost] 
public ActionMethod EditAddressType(int ID, FormCollection formValues) 
{ 
    var result = database.AddressType.Single(a => a.ID == ID); 
    UpdateModel(result); 
    database.SaveChanges(); 
    return View("SaveSuccess"); 
} 

Der Blick ‚EditAddressType‘ stark typisiert ist und funktioniert gut, aber es gibt eine Menge von wiederholtem Code (eine Instanz dies für jedes Objekt). Mir wurde gesagt, dass ich über Reflexion nachdenken muss, aber ich weiß nicht, wie ich das umsetzen soll. Mein Verständnis ist, dass ich den Objekttyp abrufen muss, damit ich den fest codierten Verweis auf das Objekt ersetzen kann, aber ich bin mir nicht sicher, wie diese Informationen aus dem Postback abgerufen werden.

Ich hatte Erfolg, die Informationen an ViewData im Controller zu binden und das an eine ViewPage-Ansicht zu übergeben, die nach diesem ViewData suchen kann, aber ich weiß nicht, wie die Änderungen an einen Controller gesendet werden.

Danke für jede Hilfe, die Sie mir geben können!

Antwort

0

Wenn Sie das Objekt bearbeiten möchten, müssen Sie es in der POST-Aktion nicht erneut aus der Datenbank abrufen. Das erste, was natürlich wäre zu abstrakt Code meines Datenzugriff sein von der Steuerung:

public class AddressesController: Controller 
{ 
    private readonly IAddressesRepository _repository; 
    public AddressesController(IAddressesRepository repository) 
    { 
     _repository = repository; 
    } 

    public ActionMethod Edit(int id) 
    { 
     var result = _repository.GetAddress(id); 
     return View(result); 
    } 

    [HttpPut] 
    public ActionMethod Update(AddressViewModel address) 
    { 
     _repository.Save(address); 
     return View("SaveSuccess"); 
    } 
} 

Sie werden feststellen, dass ich einige der Aktionen umbenannt und Verben akzeptieren diesen Controller ein bisschen mehr RESTFul zu machen.

Die zugehörige Ansicht könnte wie folgt aussehen:

<% using (Html.BeginForm<AddressesController>(c => c.Update(null))) { %> 
    <%: Html.HttpMethodOverride(HttpVerbs.Put) %> 
    <%: Html.HiddenFor(model => model.Id) %> 
    <%: Html.TextBoxFor(model => model.Name) %> 
    <input type="submit" value="Save" /> 
<% } %> 

Was die Umsetzung dieser IAddressesRepository Schnittstelle betrifft, das ist völlig bis zu Ihnen: Entity Framework, NHibernate, XML-Datei, rufen Sie Remote-Web-Service, ..., das ist ein Implementierungsdetail, das nichts mit ASP.NET MVC zu tun hat.

+0

Das sieht vielversprechend aus. Ich werde sicherlich versuchen, mein Programm RESTful zu machen. Ich bin jedoch immer noch nicht darüber informiert, wie man das generischer machen kann, um andere Objekte als AddressType zu aktualisieren, wie UserType oder EventType, die ebenfalls eine ID- und Name-Komponente haben. Ich versuche zu vermeiden, Dinge wie AddressController oder AddressType fest zu codieren, denn wenn ich UserType aktualisieren will, werde ich den exakt gleichen Code verwenden, außer dass alle Instanzen von AddressType durch UserType ersetzt werden. – JimF

+0

In der oben gezeigten Update-Methode konnte ich die Adresse nicht speichern, weil sie den ursprünglichen Datenbankkontext verlor, wenn sie an die Ansicht übergeben wurde. Ich habe versucht, _repository.Attach (Adresse) zu verwenden, um seinen Datenkontext erneut anzuwenden, aber das löst eine Ausnahme aus. Dies war der ursprüngliche Grund, warum ich zurück in die Datenbank gegangen bin, um das ursprüngliche AddressType-Objekt zu erhalten, um ein Objekt mit dem Kontext zu haben, der notwendig ist, um UpdateModel (...) auszuführen. – JimF

Verwandte Themen