In den aktuellen Beispielen auf ASP.NET MVC sehe ich recht einfache Entitäten mit einfachen CRUD-Methoden.
Aber ich bin mir nicht sicher, was ich mit fortgeschritteneren Modellen anfangen soll. Lassen Sie mich ein Beispiel geben:
Wir haben eine Garage Website. Die Garage hat:
carparts
Employees Customers Cars , die aus allen Autos besteht, die in der Garage sind / waren Nehmen wir jetzt car , das Auto könnte eine Sammlung von employees haben, die am Auto funktioniert (abgeleitet von der ursprünglichen employee Klasse, fügt einige zusätzliche Requisiten hinzu, die ihn an das Auto binden), eine Sammlung von carparts , die ersetzt wurden (auch abgeleitet, fügt zum Beispiel SerialNr hinzu, und ReplacementDate prop) und natürlich eine customer prop des Kunden, der das Auto besitzt.
Jetzt in rest Ich möchte folgendes sehen:
Wie würde ich meine Controller bauen? Sollte ich all diese CRUD-Methoden für die untergeordneten Elemente in CarsController hinzufügen? Macht das nicht einen sehr fetten Controller wegen der vielen Methoden (dieses Modell ist übermäßig vereinfacht, das Auto hat viel mehr Eltern-Kind-Beziehungen)? Oder sollte ich einen EmployeesInCar Controller erstellen (scheint schlecht) ...
Vielen Dank.
BEARBEITEN:
Zunächst einmal ist das Beispiel nur hypothetisch, nur ein Beispiel.
Wenn ich dem Vorschlag folge, würde ich ein CarController haben, das nur Autos behandelt. Und mein PartsController würde nur mit Parts umgehen. Aber wir haben zwei Sätze von Part s, eine allgemeine (für das Inventar); und wir haben ein Part in einem Auto, das von dem allgemeinen abgeleitet ist, aber Eigenschaften wie SerialNumber und ReplacementDate hinzufügt.
So wird mein Parts-Controller ziemlich fett, für das Beispiel rufen wir die Entitäten auf: GeneralPart (in Inventory) und SpecificPart (die abgeleitete Klasse mit den zusätzlichen Eigenschaften)
Weil jede Aktion entweder einen allgemeinen Teil oder einen bestimmten Teil behandelt. Das gleiche gilt für Mitarbeiter, wir haben die Basis-Mitarbeiterklasse und eine spezifische Mitarbeiterklasse mit zusätzlichen Eigenschaften.
Wenn Sie die Pfade verwenden möchten, die Sie in Ihrem Beispiel angegeben haben, dann sollten Sie lernen, wie Sie die Routing-Engine in .NET 3.5 verwenden. Sie sollten in der Lage sein, die Arten von URLs zu verwenden, die Sie benötigen, aber Sie müssen mehrere benutzerdefinierte Routen und wahrscheinlich einen benutzerdefinierten Routen-Handler erstellen, um dies zu erreichen. Die Routing-Engine in .NET 3.5 ist sehr flexibel und wurde nicht speziell für MVC entwickelt ... sie ist eigentlich sehr generisch und kann eine sehr breite, wahrscheinlich unbegrenzte Auswahl an URL-Umschreibungen bieten.
Es ist ein bisschen spät, wo ich lebe, also bildet sich das Beispiel, das ich gerade schreiben wollte, nicht. : P Es genügt zu sagen, ein benutzerdefinierter Routen-Handler und einige neue Routen-Mappings sollten Sie dorthin bringen, wo Sie sein müssen.
EDIT: Das kann hilfreich sein:
EDIT 2: Ich habe Controller vorher weggelassen. Das Routing bietet Ihnen die Möglichkeit, die gewünschten URLs zu verwenden. Und das ist eine gute Sache ... die Arten von URLs, die Sie vorgeschlagen haben, werden langfristig eine bessere SEO-Erfahrung bieten. Für die Organisation Ihrer Controller empfehle ich, es einfach zu halten:
%Vor%Ihre Routen würden Ihren URL-Mustern entsprechen und sie zu einer richtigen Route für Ihren Controller machen, indem Sie die IDs übernehmen und sie mit den Parametern Ihrer Aktionen abgleichen.
EDIT 3:
Nun, da ich Ihre Frage besser verstanden habe, hoffe ich, dass ich sie besser beantworten kann. Generell denke ich, Controller sollten 1: 1 mit Ihren Entitäten abbilden. Wenn Sie ein GeneralPart haben, sollten Sie einen Controller für die Verwaltung von allgemeinen Teilen haben. Wenn Sie CarPart besitzen, sollten Sie einen Controller haben, der speziell für die Verwaltung von Autoteilen gedacht ist. Wenn CarParts GeneralParts sind und sich in einigen Fällen wie GeneralParts verhalten können, ist es wahrscheinlich am besten, diese Verwaltungsaspekte auf dem GeneralPartsController zu haben, es sei denn, diese Verwaltung behandelt spezielle Attribute eines CarParts. In diesem Fall sollte die Verwaltung delegiert werden zu CarPartsController. Es ist sehr elegant, wie Polymorphie in die Controller-Organisation eingreift und wie die "ist-a" -Beziehung es ermöglicht, Controller wiederzuverwenden, um mehrere Typen zu verwalten.
Um ehrlich zu sein, Sie haben ein ziemlich komplexes Szenario, das ich in meiner Zeit mit ASP.NET MVC nicht direkt angetroffen habe. Ich versuche, solche Szenarien so weit wie möglich zu vermeiden, weil sie zu komplizierten Fragen wie dieser führen, die dazu neigen, in ihren Antworten subjektiv zu sein. Letztendlich sollten Sie Ihre Controller so organisieren, dass es logisch ist, wie sie verwendet werden, wie sie Ihren Entitäten zugeordnet werden und wie gut sie das Verhalten organisieren, an dem Sie interessiert sind. Manchmal ist es nicht logisch, alle Ihre Controller einer einzelnen Entität zuzuordnen. Manchmal müssen Sie einen "zusammengesetzten" Controller haben, der sich mit Aktionen befasst, die auf mehreren Entitäten gleichzeitig ausgeführt werden, oder Graphen von Entitäten. In diesen Fällen ist es wahrscheinlich am besten, Controller zu haben, die diesen bestimmten Verhaltensgruppen gewidmet sind, anstatt zu versuchen, einen Entity-spezifischen Controller zu finden, der "sorta passt".
Ihr Design sollte sich zunächst auf die Entitäten konzentrieren. Sie haben car , employees und inventory . Schreibe einen Controller für jeden von diesen. Das gibt dir die grundlegenden Routen:
/cars/{action}/{id} /employees/{action}/{id} /inventory/{action}/{id} Von hier aus sollten Sie in der Lage sein, eine neue Route mit einer benutzerdefinierten Routenbeschränkung zu schreiben mit folgender Struktur:
%Vor% Das ist auch etwas besser als /cars/{id}/carpart/{id} , weil das Wort Auto in carpart überflüssig ist. /car/.../part/ gibt an, dass der Teil für ein Auto ist.
Über solche Dinge für das URI-Design nachzudenken, ist sehr früh wichtig, weil das Ändern des URI-Designs später Suchmaschinenindizes, Lesezeichen und Links durchbricht.
Ihre Entität "CarPart" (Klasse CarPartModel) kann sich im Zustand "stock" (Klasse StockCarPartModel: CarPartModel) oder im Zustand "replaced" (Klasse ReplacedCarPartModel: CarPartModel) befinden. Dann:
Dies alles wird von "Standard" Route behandelt und in Ihrem CarPartController haben Sie Aktionen:
%Vor%Ich denke, dein Controller ist nicht fett. Es ist normal, dass der Controller mit der Modellvererbung befasst ist. Die Hauptkomplexität liegt in Ihren ViewModels und Views
Sie müssen nicht zu viele Dinge in einem Controller vor sich haben.
Stellen Sie sich einen Controller als eine Klasse vor, die bestimmt, was der Benutzer möchte und was er am Ende sehen soll.
Was der Benutzer möchte, wird von der ASP.NET MVC Engine automatisch für Sie bestimmt, mit Hilfe der Routen, die Sie in der Datei Global.asax definiert haben. Dann sollte der Controller entscheiden, welche Ansicht der Benutzer als Ergebnis der Anfrage sehen sollte.
Für Ihre Anwendung würden die Dinge also etwa so aussehen:
Global.asax
%Vor%CarsController.cs
%Vor%Im Grunde genommen würden Sie so Ihren Controller für eine solche Anwendung einrichten.
Tags und Links asp.net-mvc