Was ist ViewModel in MVC?

Question

Ich bin neu in ASP.NET MVC. Ich habe ein Problem mit dem Verständnis der Zweck eines ViewModel.

Was ist ein ViewModel und warum brauchen wir ein ViewModel für eine ASP.NET MVC-Anwendung?

Wenn ich ein gutes Beispiel für die Funktionsweise und eine Erklärung bekomme, wäre das noch besser.

Answer 1

A view model steht für die Daten, die Sie in Ihrer Ansicht/Seite anzeigen möchten, sei es für statischen Text oder für Eingabewerte (wie Textfelder und Dropdown-Listen), die der Datenbank hinzugefügt (oder bearbeitet) werden können. Es ist etwas anderes als Ihr domain model . Es ist ein Modell für die Ansicht.

Nehmen wir an, Sie haben eine Employee die das Domänenmodell Ihres Mitarbeiters darstellt und die folgenden Eigenschaften enthält (eindeutiger Bezeichner, Vorname, Nachname und Erstellungsdatum):

public class Employee : IEntity
{
     public int Id { get; set; }

     public string FirstName { get; set; }

     public string LastName { get; set; }

     public DateTime DateCreated { get; set; }
}

Ansichtsmodelle unterscheiden sich von Domänenmodellen dadurch, dass Ansichtsmodelle nur die Daten (dargestellt durch Eigenschaften) enthalten, die Sie in Ihrer Ansicht verwenden möchten. Angenommen, Sie möchten einen neuen Mitarbeiterdatensatz hinzufügen, dann könnte Ihr Ansichtsmodell wie folgt aussehen:

public class CreateEmployeeViewModel
{
     public string FirstName { get; set; }

     public string LastName { get; set; }
}

Wie Sie sehen können, enthält es nur zwei der Eigenschaften. Diese beiden Eigenschaften sind auch im Domänenmodell des Mitarbeiters enthalten. Warum ist das so, werden Sie sich fragen? Id wird möglicherweise nicht in der Ansicht festgelegt, sondern automatisch von der Tabelle "Mitarbeiter" generiert. Und DateCreated kann auch in der gespeicherten Prozedur oder in der Dienstschicht Ihrer Anwendung festgelegt werden. Also Id y DateCreated werden im Ansichtsmodell nicht benötigt. Möglicherweise möchten Sie diese beiden Eigenschaften anzeigen, wenn Sie die Details eines Mitarbeiters (eines Mitarbeiters, der bereits erfasst wurde) als statischen Text betrachten.

Beim Laden der Ansicht/Seite erstellt die Methode "create action" in Ihrem Mitarbeiter-Controller eine Instanz dieses Ansichtsmodells, füllt alle Felder aus, falls erforderlich, und übergibt dieses Ansichtsmodell dann an die Ansicht/Seite:

public class EmployeeController : Controller
{
     private readonly IEmployeeService employeeService;

     public EmployeeController(IEmployeeService employeeService)
     {
          this.employeeService = employeeService;
     }

     public ActionResult Create()
     {
          CreateEmployeeViewModel model = new CreateEmployeeViewModel();

          return View(model);
     }

     public ActionResult Create(CreateEmployeeViewModel model)
     {
          // Do what ever needs to be done before adding the employee to the database
     }
}

Ihre Ansicht/Seite könnte wie folgt aussehen (vorausgesetzt, Sie verwenden ASP.NET MVC und die Razor Ansicht Motor):

@model MyProject.Web.ViewModels.CreateEmployeeViewModel

<table>
     <tr>
          <td><b>First Name:</b></td>
          <td>@Html.TextBoxFor(m => m.FirstName, new { maxlength = "50", size = "50" })
              @Html.ValidationMessageFor(m => m.FirstName)
          </td>
     </tr>
     <tr>
          <td><b>Last Name:</b></td>
          <td>@Html.TextBoxFor(m => m.LastName, new { maxlength = "50", size = "50" })
              @Html.ValidationMessageFor(m => m.LastName)
          </td>
     </tr>
</table>

Die Validierung würde also nur bei FirstName y LastName . Verwendung von FluentValidierung könnten Sie eine solche Validierung haben:

public class CreateEmployeeViewModelValidator : AbstractValidator<CreateEmployeeViewModel>
{
     public CreateEmployeeViewModelValidator()
     {
          RuleFor(m => m.FirstName)
               .NotEmpty()
               .WithMessage("First name required")
               .Length(1, 50)
               .WithMessage("First name must not be greater than 50 characters");

          RuleFor(m => m.LastName)
               .NotEmpty()
               .WithMessage("Last name required")
               .Length(1, 50)
               .WithMessage("Last name must not be greater than 50 characters");
     }
}

Und mit Data Annotations könnte es so aussehen:

public class CreateEmployeeViewModel : ViewModelBase
{
    [Display(Name = "First Name")]
    [Required(ErrorMessage = "First name required")]
    public string FirstName { get; set; }

    [Display(Name = "Last Name")]
    [Required(ErrorMessage = "Last name required")]
    public string LastName { get; set; }
}

Das Wichtigste dabei ist, dass das Ansichtsmodell nur die Daten darstellt, die Sie verwenden möchten und sonst nichts. Sie können sich den ganzen unnötigen Code und die Validierung vorstellen, wenn Sie ein Domänenmodell mit 30 Eigenschaften haben und Sie nur einen einzigen Wert aktualisieren wollen. In diesem Szenario würden Sie nur diesen einen Wert/diese eine Eigenschaft im Ansichtsmodell haben und nicht alle Eigenschaften, die im Domänenobjekt vorhanden sind.

Ein View-Modell kann nicht nur Daten aus einer Datenbanktabelle enthalten. Es kann auch Daten aus einer anderen Tabelle kombinieren. Nehmen Sie mein obiges Beispiel zum Hinzufügen eines neuen Mitarbeiterdatensatzes. Neben dem Vor- und Nachnamen möchten Sie vielleicht auch die Abteilung des Mitarbeiters hinzufügen. Diese Liste der Abteilungen stammt aus Ihrer Departments Tisch. Jetzt haben Sie also Daten aus der Employees y Departments Tabellen in einem View-Modell. Sie müssen dann nur noch die folgenden beiden Eigenschaften zu Ihrem Ansichtsmodell hinzufügen und es mit Daten befüllen:

public int DepartmentId { get; set; }

public IEnumerable<Department> Departments { get; set; }

Bei der Bearbeitung von Mitarbeiterdaten (eines Mitarbeiters, der bereits zur Datenbank hinzugefügt wurde) würde sich nicht viel von meinem obigen Beispiel unterscheiden. Erstellen Sie ein View Model, rufen Sie es z.B. auf EditEmployeeViewModel . Geben Sie nur die Daten ein, die Sie in diesem Ansichtsmodell bearbeiten möchten, z. B. Vor- und Nachname. Bearbeiten Sie die Daten und klicken Sie auf die Schaltfläche "Senden". Ich würde mir nicht zu viele Gedanken über die Id Feld, weil die Id Wert wird zum Beispiel in der URL enthalten sein:

http://www.yourwebsite.com/Employee/Edit/3

Nimm dies Id und leiten es zusammen mit den Werten für Vor- und Nachname an Ihre Repository-Ebene weiter.

Beim Löschen eines Datensatzes gehe ich normalerweise denselben Weg wie beim Modell der Bearbeitungsansicht. Ich würde auch eine URL haben, zum Beispiel:

http://www.yourwebsite.com/Employee/Delete/3

Wenn die Ansicht zum ersten Mal geladen wird, würde ich die Daten des Mitarbeiters aus der Datenbank abrufen, indem ich die Id von 3. Ich würde dann nur statischen Text auf meiner Ansicht/Seite anzeigen, damit der Benutzer sehen kann, welcher Mitarbeiter gelöscht wird. Wenn der Benutzer auf die Schaltfläche Löschen klickt, würde ich einfach die Id Wert von 3 und übergebe ihn an meine Repository-Ebene. Sie brauchen nur die Id um einen Datensatz aus der Tabelle zu löschen.

Ein weiterer Punkt ist, dass man nicht wirklich für jede Aktion ein View Model braucht. Wenn es sich um einfache Daten handelt, dann wäre es in Ordnung, nur EmployeeViewModel . Wenn es sich um komplexe Ansichten/Seiten handelt und sie sich voneinander unterscheiden, würde ich vorschlagen, dass Sie für jede Ansicht ein eigenes Modell verwenden.

Ich hoffe, dass dies die Verwirrung, die Sie über Ansichtsmodelle und Domänenmodelle hatten, ausräumt.

Answer 2

Modell ansehen ist eine Klasse, die das in einer bestimmten Ansicht verwendete Datenmodell darstellt. Wir könnten diese Klasse als Modell für eine Anmeldeseite verwenden:

public class LoginPageVM
{
    [Required(ErrorMessage = "Are you really trying to login without entering username?")]
    [DisplayName("Username/e-mail")]
    public string UserName { get; set; }
    [Required(ErrorMessage = "Please enter password:)")]
    [DisplayName("Password")]
    public string Password { get; set; }
    [DisplayName("Stay logged in when browser is closed")]
    public bool RememberMe { get; set; }
}

Anhand dieses Ansichtsmodells können Sie die Ansicht definieren (Razor View Engine):

@model CamelTrap.Models.ViewModels.LoginPageVM

@using (Html.BeginForm()) {
    @Html.EditorFor(m => m);
    <input type="submit" value="Save" class="submit" />
}

Und Aktionen:

[HttpGet]
public ActionResult LoginPage()
{
    return View();
}

[HttpPost]
public ActionResult LoginPage(LoginPageVM model)
{
    ...code to login user to application...
    return View(model);
}

Dies führt zu folgendem Ergebnis (der Bildschirm wird nach dem Absenden des Formulars mit den Validierungsmeldungen angezeigt):

Wie Sie sehen können, hat ein Ansichtsmodell viele Funktionen:

• Ansichtsmodelle dokumentieren eine Ansicht, indem sie nur aus Feldern bestehen, die in der Ansicht dargestellt werden.
• Ansichtsmodelle können spezifische Validierungsregeln unter Verwendung von Datenannotationen oder IDataErrorInfo enthalten.
• Das Ansichtsmodell definiert, wie eine Ansicht aussehen soll (für LabelFor , EditorFor , DisplayFor Helfern).
• Ansichtsmodelle können Werte aus verschiedenen Datenbankentitäten kombinieren.
• Sie können auf einfache Weise Anzeigevorlagen für View-Modelle spezifizieren und sie an vielen Stellen mit DisplayFor- oder EditorFor-Helfern wiederverwenden.

Ein weiteres Beispiel für ein Ansichtsmodell und dessen Abruf: Wir möchten grundlegende Benutzerdaten, seine Rechte und seinen Benutzernamen anzeigen. Wir erstellen ein spezielles Ansichtsmodell, das nur die erforderlichen Felder enthält. Wir rufen Daten von verschiedenen Entitäten aus der Datenbank ab, aber die Ansicht kennt nur die Klasse des Ansichtsmodells:

public class UserVM {
    public int ID { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public bool IsAdministrator { get; set; }
    public string MothersName { get; set; }
}

Abruf:

var user = db.userRepository.GetUser(id);

var model = new UserVM() {
   ID = user.ID,
   FirstName = user.FirstName,
   LastName = user.LastName,
   IsAdministrator = user.Proviledges.IsAdministrator,
   MothersName = user.Mother.FirstName + " " + user.Mother.LastName
}

Answer 3

Edit: Ich habe diese Antwort in meinem Blog aktualisiert:

http://www.samwheat.com/post/The-function-of-ViewModels-in-MVC-web-development

Meine Antwort ist etwas langatmig, aber ich denke, es ist wichtig, Ansichtsmodelle mit anderen Arten von häufig verwendeten Modellen zu vergleichen, um zu verstehen, warum sie anders sind und warum sie notwendig sind.

Zusammenfassend und um die gestellte Frage direkt zu beantworten:

Im Allgemeinen ist ein Ansichtsmodell ein Objekt, das alle Eigenschaften und Methoden enthält, die für die Darstellung einer Ansicht erforderlich sind. Die Eigenschaften des Ansichtsmodells beziehen sich häufig auf Datenobjekte wie Kunden und Aufträge und enthalten darüber hinaus auch Eigenschaften, die sich auf die Seite oder die Anwendung selbst beziehen, wie z. B. den Benutzernamen, den Anwendungsnamen usw. View-Modelle bieten ein praktisches Objekt, das an eine Rendering-Engine übergeben werden kann, um eine HTML-Seite zu erstellen. Einer der vielen Gründe für die Verwendung eines View-Modells ist, dass View-Modelle eine Möglichkeit bieten, bestimmte Präsentationsaufgaben wie die Verarbeitung von Benutzereingaben, die Validierung von Daten, das Abrufen von Daten für die Anzeige usw. zu testen.

Hier ein Vergleich von Entitätsmodellen (auch DTOs oder Modelle genannt), Präsentationsmodellen und Ansichtsmodellen.

Datenübertragungsobjekte, auch bekannt als "Modell"

Ein Datentransferobjekt (DTO) ist eine Klasse mit Eigenschaften, die einem Tabellenschema in einer Datenbank entsprechen. DTOs sind so benannt, weil sie häufig für die Übertragung von Daten zu und von einem Datenspeicher verwendet werden.
Merkmale von DTOs:

• sind Geschäftsobjekte - ihre Definition ist abhängig von den Anwendungsdaten.
• Sie enthalten in der Regel nur Eigenschaften - keinen Code.
• Wird in erster Linie für den Transport von Daten zu und von einer Datenbank verwendet.
• Eigenschaften stimmen genau oder sehr genau mit Feldern in einer bestimmten Tabelle in einem Datenspeicher überein.

Datenbanktabellen sind in der Regel normalisiert, daher sind auch DTOs in der Regel normalisiert. Dadurch sind sie für die Darstellung von Daten nur bedingt geeignet. Für bestimmte einfache Datenstrukturen eignen sie sich jedoch oft recht gut.

Hier sind zwei Beispiele, wie DTOs aussehen könnten:

public class Customer
{
    public int ID { get; set; }
    public string CustomerName { get; set; }
}

public class Order
{
    public int ID { get; set; }
    public int CustomerID { get; set; }
    public DateTime OrderDate { get; set; }
    public Decimal OrderAmount { get; set; }
}

Präsentation Modelle

Ein Präsentationsmodell ist ein Dienstprogramm Klasse, die zur Darstellung von Daten auf einem Bildschirm oder in einem Bericht verwendet wird. Präsentationsmodelle werden in der Regel verwendet, um komplexe Datenstrukturen zu modellieren, die aus Daten von mehreren DTOs bestehen. Präsentationsmodelle stellen oft eine denormalisierte Sicht der Daten dar.

Merkmale von Präsentationsmodellen:

• sind Geschäftsobjekte - ihre Definition ist abhängig von den Anwendungsdaten.
• Enthalten meist Eigenschaften. Der Code beschränkt sich in der Regel auf die Formatierung von Daten oder deren Konvertierung in oder aus einem DTO. Präsentationsmodelle sollten keine Geschäftslogik enthalten.
• Sie zeigen oft eine denormalisierte Ansicht der Daten. Das heißt, sie kombinieren oft Eigenschaften aus mehreren DTOs.
• Enthalten oft Eigenschaften eines anderen Basistyps als ein DTO. Beispielsweise können Dollarbeträge als Zeichenketten dargestellt werden, so dass sie Kommas und ein Währungssymbol enthalten können.
• Oftmals werden sie durch ihre Verwendung und die Eigenschaften ihrer Objekte definiert. Mit anderen Worten, ein einfaches DTO, das als Backing Model für die Darstellung eines Gitters verwendet wird, ist in Wirklichkeit auch ein Präsentationsmodell im Kontext dieses Gitters.

Präsentationsmodelle werden "nach Bedarf" und "bei Bedarf" verwendet (während DTOs normalerweise an das Datenbankschema gebunden sind). Ein Präsentationsmodell kann verwendet werden, um Daten für eine ganze Seite, ein Gitter auf einer Seite oder ein Dropdown in einem Gitter auf einer Seite zu modellieren. Präsentationsmodelle enthalten oft Eigenschaften, die andere Präsentationsmodelle darstellen. Präsentationsmodelle werden oft für einen einmaligen Zweck konstruiert, z. B. um ein bestimmtes Raster auf einer einzelnen Seite darzustellen.

Ein Beispiel für ein Präsentationsmodell:

public class PresentationOrder
{
    public int OrderID { get; set; }
    public DateTime OrderDate { get; set; }
    public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
    public string CustomerName { get; set; }
    public Decimal OrderAmount { get; set; }
    public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}

Modelle ansehen

Ein Ansichtsmodell ähnelt einem Präsentationsmodell insofern, als es eine unterstützende Klasse für die Darstellung einer Ansicht ist. Es unterscheidet sich jedoch stark von einem Präsentationsmodell oder einem DTO in der Art, wie es aufgebaut ist. View-Modelle enthalten oft dieselben Eigenschaften wie Präsentationsmodelle und DTOs, weshalb sie oft verwechselt werden.

Merkmale von Ansichtsmodellen:

• sind die einzige Datenquelle, die zum Rendern einer Seite oder eines Bildschirms verwendet wird. In der Regel bedeutet dies, dass ein Ansichtsmodell alle Eigenschaften bereitstellt, die jedes Steuerelement auf der Seite benötigt, um sich selbst korrekt darzustellen. Dadurch, dass das View-Modell die einzige Datenquelle für die Ansicht ist, werden seine Fähigkeiten und sein Wert für Unit-Tests erheblich verbessert.
• Sind zusammengesetzte Objekte die sowohl Eigenschaften enthalten, die aus Anwendungsdaten bestehen, als auch Eigenschaften, die vom Anwendungscode verwendet werden. Dieses Merkmal ist entscheidend für die Wiederverwendbarkeit des View-Modells und wird in den folgenden Beispielen erläutert.
• Enthält Anwendungscode. View Models enthalten normalerweise Methoden, die während des Renderings und der Interaktion des Benutzers mit der Seite aufgerufen werden. Dieser Code bezieht sich in der Regel auf Ereignisbehandlung, Animation, Sichtbarkeit von Steuerelementen, Styling usw.
• Enthält Code, der Geschäftsdienste aufruft, um Daten abzurufen oder an einen Datenbankserver zu senden. Dieser Code wird oft fälschlicherweise in einem Controller platziert. Der Aufruf von Geschäftsdiensten von einem Controller aus schränkt in der Regel die Nützlichkeit des View-Modells für Unit-Tests ein. Um das klarzustellen: View-Modelle selbst sollten keine Geschäftslogik enthalten, aber sie sollten Dienste aufrufen, die Geschäftslogik enthalten.
• Sie enthalten oft Eigenschaften, die andere Ansichtsmodelle für andere Seiten oder Bildschirme darstellen.
• werden "pro Seite" oder "pro Bildschirm" geschrieben. In der Regel wird für jede Seite oder jeden Bildschirm in einer Anwendung ein eigenes Ansichtsmodell geschrieben.
• Sie leiten sich in der Regel von einer Basisklasse ab, da die meisten Seiten und Bildschirme gemeinsame Eigenschaften haben.

Ansicht Modellzusammensetzung

Wie bereits erwähnt, sind Ansichtsmodelle zusammengesetzte Objekte, da sie Anwendungseigenschaften und Geschäftsdateneigenschaften in einem einzigen Objekt kombinieren. Beispiele für häufig verwendete Anwendungseigenschaften, die in Ansichtsmodellen verwendet werden, sind:

• Eigenschaften, die zur Anzeige des Anwendungsstatus verwendet werden, wie Fehlermeldungen, Benutzername, Status usw.
• Eigenschaften, die zum Formatieren, Anzeigen, Stilisieren oder Animieren von Steuerelementen verwendet werden.
• Eigenschaften, die für die Datenbindung verwendet werden, z. B. Listenobjekte und Eigenschaften, die Zwischendaten enthalten, die vom Benutzer eingegeben werden.

Die folgenden Beispiele zeigen, warum die zusammengesetzte Natur von View-Modellen wichtig ist und wie wir am besten ein effizientes und wiederverwendbares View-Modell konstruieren können.

Nehmen wir an, wir schreiben eine Webanwendung. Eine der Anforderungen an das Anwendungsdesign ist, dass der Seitentitel, der Benutzername und der Anwendungsname auf jeder Seite angezeigt werden müssen. Wenn wir eine Seite erstellen wollen, die ein Präsentationsauftragsobjekt anzeigt, können wir das Präsentationsmodell wie folgt ändern:

public class PresentationOrder
{
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }
    public int OrderID { get; set; }
    public DateTime OrderDate { get; set; }
    public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
    public string CustomerName { get; set; }
    public Decimal OrderAmount { get; set; }
    public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}

Dieses Design könnte funktionieren aber was, wenn wir eine Seite erstellen wollen, die eine Liste von Bestellungen anzeigt? Die Eigenschaften "PageTitle", "UserName" und "ApplicationName" werden sich wiederholen und die Arbeit damit wird unhandlich. Und was ist, wenn wir im Konstruktor der Klasse eine Logik auf Seitenebene definieren wollen? Das ist nicht mehr möglich, wenn wir für jede Bestellung, die angezeigt werden soll, eine Instanz erstellen.

Komposition über Vererbung

Hier ist ein Weg, wie wir das Präsentationsmodell der Bestellung so umgestalten können, dass es ein echtes Ansichtsmodell wird und für die Anzeige eines einzelnen PresentationOrder-Objekts oder einer Sammlung von PresentationOrder-Objekten nützlich ist:

public class PresentationOrderVM
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business properties
    public PresentationOrder Order { get; set; }
}

public class PresentationOrderVM
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business properties
    public List<PresentationOrder> Orders { get; set; }
}

Wenn wir uns die beiden oben genannten Klassen ansehen, können wir erkennen, dass es sich bei einem Ansichtsmodell um ein Präsentationsmodell handelt, das ein anderes Präsentationsmodell als Eigenschaft enthält. Das Präsentationsmodell der obersten Ebene (d. h. das Ansichtsmodell) enthält Eigenschaften, die für die Seite oder Anwendung relevant sind, während das Präsentationsmodell (Eigenschaft) Eigenschaften enthält, die für die Anwendungsdaten relevant sind.

Wir können einen Schritt weiter gehen und eine Basis-View-Modell-Klasse erstellen, die nicht nur für PresentationOrders, sondern auch für jede andere Klasse verwendet werden kann:

public class BaseViewModel
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }
}

Jetzt können wir unsere PresentationOrderVM wie folgt vereinfachen:

public class PresentationOrderVM : BaseViewModel
{
    // Business properties
    public PresentationOrder Order { get; set; }
}

public class PresentationOrderVM : BaseViewModel
{
    // Business properties
    public List<PresentationOrder> Orders { get; set; }
}

Wir können unser BaseViewModel noch besser wiederverwendbar machen, indem wir es generisch machen:

public class BaseViewModel<T>
{
    // Application properties
    public string PageTitle { get; set; }
    public string UserName { get; set; }
    public string ApplicationName { get; set; }

    // Business property
    public T BusinessObject { get; set; }
}

Jetzt sind unsere Implementierungen mühelos:

public class PresentationOrderVM : BaseViewModel<PresentationOrder>
{
    // done!
}

public class PresentationOrderVM : BaseViewModel<List<PresentationOrder>>
{
    // done!
}

Answer 4

Ich habe nicht alle Beiträge gelesen, aber in jeder Antwort scheint ein Konzept zu fehlen, das mir wirklich geholfen hat, es zu "verstehen"...

Wenn ein Modell mit einer Datenbank vergleichbar ist Tabelle dann ist ein ViewModel mit einer Datenbank vergleichbar 表示 - Eine Ansicht liefert in der Regel entweder kleine Datenmengen aus einer Tabelle oder komplexe Datensätze aus mehreren Tabellen (Joins).

Ich finde mich mit ViewModels, um die Informationen in eine Ansicht/Formular übergeben, und dann die Übertragung dieser Daten in ein gültiges Modell, wenn das Formular Beiträge zurück an den Controller - auch sehr praktisch für die Speicherung von Lists(IEnumerable).

Answer 5

Wenn Sie Eigenschaften haben, die für die Ansicht spezifisch sind und sich nicht auf die DB/Service/Datenspeicher beziehen, ist es eine gute Praxis, ViewModels zu verwenden. Nehmen wir an, Sie wollen ein Kontrollkästchen auf der Grundlage eines DB-Feldes (oder zweier) ausgewählt lassen, aber das DB-Feld selbst ist kein Boolescher Wert. Es ist zwar möglich, diese Eigenschaften im Model selbst zu erstellen und sie vor der Bindung an Daten zu verbergen, aber je nach der Anzahl solcher Felder und Transaktionen möchten Sie das Model vielleicht nicht überladen.

Wenn es zu wenige ansichtsspezifische Daten und/oder Transformationen gibt, können Sie das Modell selbst verwenden