Sollte die Sortierlogik im Modell, in der Ansicht oder in der Steuerung platziert werden? [geschlossen]

Ich habe eine Dropdown-Liste, die dem Endbenutzer Werte aus einer Tabelle anzeigt. Ich möchte, dass diese Werte alphabetisch sortiert werden.

Auf welcher Ebene sollte ich gemäß dem richtigen MVC-Design meine Sortierlogik platzieren: das Modell, die Ansicht oder den Controller?

BEARBEITEN : Als Antwort auf LarsHs Frage "Meinst du Code, der bestimmt, welche Sortierreihenfolge gewünscht wird? Oder Code, der die Sortierung ausführt?", Bezog ich mich ursprünglich auf den Code, der bestimmt, welche Sortierreihenfolge gewünscht wird.

(Hinweis: Dieses Zitat und Zitat stammt aus der Antwort von @ dasblinkenlight , aber wir sind uns nicht einig über unsere Interpretation. Lesen Sie seinen Beitrag und entscheiden Sie sich selbst).

Nach MVC Beschreibung ,

Ein Controller kann Befehle an die zugehörige Ansicht senden, um die Darstellung des Modells in der Ansicht zu ändern (z. B. durch Scrollen durch ein Dokument). Es kann Befehle an das Modell senden, um den Status des Modells zu aktualisieren (z. B. Bearbeiten eines Dokuments).

Die Sortierlogik (z. B. der Sortierkomparator / Sortieralgorithmus) gehört zum Modell, da sie Geschäftsregeln und Statusdaten enthält. Da das Ändern der Art und Weise, wie die Modelldaten sortiert werden, direkt in die Kategorie "Darstellung des Modells in der Ansicht ändern" fällt, ist der Controller für das "Sortieren" verantwortlich, indem er die model.changeSortedState () -Methode aufruft.

Wer kontrolliert die Sortierreihenfolge?

(Aus Wikipedia )

1) Natürliche Ordnung innerhalb der Daten selbst:

Die Bestellung ist Teil des Modells, daher sollte sie dorthin gehen. Ein roher Abzug von "allen Daten" würde die Daten in der sortierten Reihenfolge zurückgeben, und es gibt keine Schnittstelle zur Auswahl der Sortierreihenfolge.

2) Der Benutzer sollte steuern, wie er die Daten sieht:

Die Ansicht bietet eine Schnittstelle (z. B. aufsteigende / absteigende Pfeile), die mit dem Controller interagiert, und das Modell versteht die Daten gut genug, um die angeforderte Sortierung der Daten durchzuführen. Im Gegensatz zu (1) muss ein Rohzug der Daten jedoch nicht unbedingt sortiert werden.

In beiden Fällen,

Die Ansicht versteht nicht, dass eine Sortierung stattfindet, außer der Fähigkeit, anzuzeigen, welche Sortierrichtung gewählt wurde. Setzen Sie die Logik nicht dort.

Kleine Einschränkung

Die Sortierfunktion könnte unter einem Umstand (den ich mir spontan vorstellen kann; es kann mehr geben) nur in der Ansicht enthalten sein:

Eine "dumme" Sortierung, bei der alle Daten bereits in der Ansicht enthalten sind und für die Sortierung kein Domänenwissen erforderlich ist. Zum Beispiel ein sehr einfacher String- oder Zahlenvergleich. Dies ist beispielsweise bei Suchergebnissen auf einer Webseite nicht möglich, wenn die Ergebnisse wahrscheinlich auf mehrere Seiten verteilt sind.

Nach MVC Beschreibung ,

Ein Controller kann Befehle an die zugehörige Ansicht senden, um die Darstellung des Modells in der Ansicht zu ändern (z. B. durch Scrollen durch ein Dokument). Es kann Befehle an das Modell senden, um den Status des Modells zu aktualisieren (z. B. Bearbeiten eines Dokuments).

Demnach gehört die Sortierlogik in die Steuerung, da das Ändern der Art und Weise, wie die Modelldaten sortiert werden, direkt in die Kategorie "Darstellung des Modells in der Ansicht ändern" fällt.

BEARBEITEN: Um mehrere in den Kommentaren geäußerte Missverständnisse zu klären, ist die "Sortierlogik" nicht der Code, der die Sortierung durchführt. Es ist der Code, der die Sortierung definiert . Die Sortierlogik vergleicht einzelne Elemente miteinander, um eine Reihenfolge festzulegen (z. B. durch eine Instanz von IComparator<T>), oder enthält eine Logik, die ein Objekt erstellt, das von einem externen System (z. B. durch eine Instanz von IOrderedQueryable<T>) zum Bestellen verwendet werden soll . Diese Logik gehört in Ihren Controller, da sie Kenntnisse in Bezug auf die "geschäftliche" Seite Ihrer Anwendung benötigt. Es ist völlig ausreichend , um die Art zu erfüllen, aber es ist getrennt von dem Code, der tatsächlich führtes. Der zu sortierende Code befindet sich möglicherweise in Ihrer Ansicht, in Ihrem Modell oder sogar in der Persistenzschicht, die Ihr Modell unterstützt (z. B. Ihre SQL-Datenbank).

Nichts des oben Genannten. Sortieren ist Geschäftslogik, und Geschäftslogik gehört zu keiner der drei. Nicht jeder Code in Ihrer Anwendung ist ein Modell, eine Ansicht oder ein Controller.

In meinen MVC-Apps habe ich normalerweise eine Service-Schicht, die die gesamte Geschäftslogik ausführt. Die Methoden in der Serviceschicht sollten eine saubere, einfache API mit gut benannten Parametern haben. Sie können diese Methoden dann von Ihrem Controller aus aufrufen, um die Daten in den Modellen zu bearbeiten.

In diesem Sinne ist die Sortierung "in der Steuerung", aber der Code selbst, der die Sortierung vornimmt, sollte nicht in der Steuerung implementiert, sondern nur von dort aufgerufen werden.

Auf keinen Fall der Controller: Er sendet Nachrichten zum Anzeigen und Modellieren, sollte aber so wenig Arbeit wie möglich leisten. Wenn der Benutzer die Sortierung ändern kann, wird diese Anforderung von der Steuerung verarbeitet, indem er das Modell oder die Ansicht darüber informiert.

Vielleicht die Ansicht, wenn es eine reine Ansichtssache ist. Wenn die Anwendung ohne Sortierung genauso gut funktioniert, ist die Sortierung nur ein Teil der Darstellung und sollte in die Ansicht aufgenommen werden.

Wenn die Reihenfolge Teil der Domäne ist, sollte sie in das Modell aufgenommen werden.

• Ansichten sind der Teil von MVC, der Präsentationslogik enthalten soll.
• In der Modellebene ist die Geschäftslogik enthalten.
• Controller ändern nur den Status von beiden basierend auf Benutzereingaben.

Die Wahl ist also: Glauben Sie, dass dies Teil der Geschäftslogik oder Präsentationslogik der Domäne ist?

Wenn Sie ein korrektes MVC-Modell2 oder ein klassisches MVC-Muster implementieren, würde ich sagen, dass die Reihenfolge der von der Modellebene bereitgestellten Daten durch die Anforderung der Ansicht an die Modellebene ausgelöst werden sollte. View fragt nach geordneten Daten, die Modellebene stellt sie bereit.

Da Sie jedoch die Interpretation des MVC-Musters von ASP.NET MVC verwenden, die sich etwas von Ihrer Standard-MVC unterscheidet, sollte die ViewModel-Instanz geordnete Informationen von der Modellebene anfordern (aus irgendeinem Grund ist das ASP.NET-Framework der Ansicht, dass Vorlagen aufgerufen werden sollten "Ansichten" und Ansichten sollten "Ansichtsmodelle" genannt werden (es ist seltsam).

Normalerweise würde ich es im Controller tun, um gemäß den anderen Antworten im Einklang mit dem Muster zu bleiben. Begründung siehe unten.

Ich habe darüber nachgedacht und die Antworten und das dazugehörige Material gelesen. Pragmatisch gesehen würde ich sagen, dass dies von Ihrer Bewerbung abhängt, zum Beispiel:

Handelt es sich um eine mittlere / große Anwendung und / oder sind mehrere Benutzeroberflächen zugeordnet (z. B. eine Windows-App, eine Webschnittstelle und eine Telefonschnittstelle).

• In diesem Fall würde ich wahrscheinlich eine Service-Schicht erstellen und in das Geschäftsobjekt einfügen und dann die entsprechende Methode vom Controller aufrufen.

Wenn es sich um eine gut definierte Website mit einer einzigen Benutzeroberfläche handelt und Sie etwas wie EF Code First verwenden und nicht die Absicht haben oder nicht beabsichtigen, eine Service-Schicht zu erstellen, und planen, eine einfache, sofort einsatzbereite Erweiterungsmethode zu verwenden, um diese zu erreichen:

• In diesem Fall würde ich es wahrscheinlich in den Controller einfügen, da es pragmatisch in Bezug auf Zeit / Budget am besten passt.

Wenn es dasselbe wie das obige ist, kann es jedoch nicht mit einer sofort einsatzbereiten Erweiterungsmethode implementiert werden.

• Ich kann mich durchaus dafür entscheiden, es in die Model-Klasse aufzunehmen (wenn es wirklich auf diesen einzelnen Typ zugeschnitten ist), da es hier geeigneter wäre als in einem Controller. Wenn die Sortierung auf mehr als eine Klasse angewendet werden könnte, würde ich sie in einer Erweiterungsmethode implementieren und dann im Controller aufrufen.

Um zusammenzufassen:

Dogmatische Antwort: Service Layer

Pragmatische Antwort: Normalerweise der Controller

Ich würde vorschlagen, Daten aus einer Tabelle zu sortieren - Daten, die klein genug sind, um in einer Dropdown-Liste nützlich zu sein - sollten aus der Datenbank stammen, die bereits über die Abfrage sortiert wurde. Für mich ist das Modell der Ort, an dem die Sortierung angewendet wird.

Wenn Sie entschlossen sind, die Sortierung von Hand durchzuführen, gibt es meiner Meinung nach gute Argumente dafür, entweder das Modell oder den Controller als bevorzugten Ort für die Logik zu verwenden. Die Einschränkung wäre Ihr spezieller Rahmen. Ich bevorzuge es, Daten ausschließlich im Modell zu verwalten. Ich benutze den Controller, um Daten (Modell) und Präsentation (Ansicht) zu heiraten, wie ich es mir selbst beigebracht habe.

Obwohl ich im Prinzip der Idee zustimme, dass Sortieren Business Logic ist, weil Sie durch Aufschlüsselung nach dem Ursprung etwas wie "Der Kunde möchte, dass die Produktseite mit den nach Datum sortierten Bildern angezeigt wird" erhalten, wird klar, dass Die Sortierreihenfolge für Daten ist normalerweise nicht willkürlich - auch wenn keine Sortierung erfolgt, da dies immer noch eine Geschäftsentscheidung durch Auslassung ist (eine leere Liste ist immer noch eine Liste).

ABER ... Diese Antwort scheint die Fortschritte in der ORM-Technologie nicht zu berücksichtigen. Ich kann nur in Bezug auf das Entity Framework (vermeiden wir einen Streit darüber, ob dies wahres ORM ist, das ist nicht der Punkt) von Microsoft as sprechen Das ist, was ich benutze, aber ich bin sicher, dass andere ORMs ähnliche Funktionen bieten.

Wenn ich mit MS MVC und dem Entity Framework eine stark typisierte Ansicht für eine Produktklasse erstelle und eine Fremdschlüsselbeziehung zwischen der Produkt- und der Image-Tabelle (z. B. FK_Product_Image_ProductId) besteht, kann ich sofort schnell sortieren die Bilder während ihrer Anzeige mit so etwas in der Ansicht:

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }

Es wurde eine bestimmte Business Logic-Schicht erwähnt, mit der ich auch 80% meiner Geschäftslogik ausführe, aber ich werde keine Sortierfunktionalität in meine Business Logic-Schicht schreiben, die etwas nachahmt, das sofort einsatzbereit ist aus dem Entity Framework.

Ich glaube nicht, dass es eine richtige Antwort auf diese Frage gibt, außer das zu sagen. Sie sollten komplexe Geschäftslogik nach Möglichkeit abstrahieren, jedoch nicht auf Kosten der Neuerfindung des Rads.

Angenommen, Sie haben eine MVC-Website, eine WebForms-Website und eine mobile Anwendung.

Wenn Sie möchten, dass die Sortierung zwischen diesen Präsentationsebenen konsistent ist, würde ich sagen, dass Sie außerhalb der Präsentationsebene sortieren. Service wäre ein guter Kandidat.

Andernfalls würde ich diese Logik in einem Ansichtsmodell speichern. Warum? Weil es wiederverwendbar und leicht testbar ist.

Von den drei, die Sie aufgelistet haben, würde ich sagen, dass es in den Controller gehört. Ich mag es jedoch nicht wirklich, diese Art von Logik in den Controller zu setzen. Normalerweise erstelle ich eine Serviceschicht, mit der der Controller kommuniziert und die für die Kommunikation mit dem Datenspeicher und die Sortierlogik verantwortlich ist. Für kleine Anwendungen ist es jedoch in Ordnung, im Controller zu sitzen.

Dies ist eine Frage, die im Hinblick auf asp.net gestellt wurde, aber da jemand Rails erwähnt hat, hielt ich es für interessant, das Problem in diesem Zusammenhang zu betrachten. In Rails ist es natürlich und ziemlich üblich, die Sortierung zusammen mit dem Abruf als Controller-Aktion durchzuführen, da das Framework und die ActiveRecord / ActiveQuery-API dies vorsehen. Auf der anderen Seite ist es möglich, eine benutzerdefinierte Sortierreihenfolge für statische Elemente zu definieren und diese in das vom Controller zu verwendende Modell einzufügen, damit das Modell eine Rolle in der Sortierlogik spielen kann, obwohl dies nicht ausgeführt wird die Operation direkt. Was auch immer es ist, man kann mit Sicherheit sagen, dass es im Allgemeinen verpönt ist, die Sortierlogik in die Ansicht aufzunehmen.

Ich bin ein wenig amüsiert darüber, dass einige Antworten absolut dagegen sind, die Sortierung entweder in den Controller oder in das Modell einzufügen, und ich finde sie für meinen Geschmack zu pedantisch, aber ich nehme an, dass dies von der Art des verwendeten Frameworks und den damit verbundenen üblichen Konventionen abhängt es. Ich stimme auch der Bemerkung von Bill K zu, dass die Trennung an erster Stelle wichtiger ist.