2012-04-08 4 views
0

Ich entwickle .NET-Wrapper über einen Service, bei der folgenden Einrichtungen vorhanden sind:entsprechende Muster für gegebenes Szenario

  • Wurzel Eigenschaften Name, Dateien, Ordner, Artikel
  • Artikel Eigenschaften Name, Methoden erstellen, Umbenennen, löschen
  • Datei Eigenschaften Name, Methoden erstellen, Umbenennen, löschen
  • Ordner Eigenschaften Name, Dateien, Ordner, Methoden erstellen, Umbenennen, Löschen

Wie Sie, Root-Rechtsträger sehen (die Singleton ist) können einige Dateien, Ordner und Elemente halten. Elemente können nur von Root gehalten werden, die in keinem Ordner vorhanden sein können. Auf der anderen Seite können Dateien und Ordner sowohl von Root- als auch von Ordner-Entities verwendet werden.

Ich versuche herauszufinden, was wäre der beste Weg, dieses Szenario in Code zu projizieren.

Service.Root wird eine Singleton-Eigenschaft sein, wahrscheinlich gibt es nicht viel mehr.

Service.Root.Files & Service.Root.Folders - Soll ich für diesen Zweck benutzerdefinierte Sammlungen von Datei- und Ordnerklassen erstellen? Und wenn ja, sollte es möglich sein, neue Instanzen von Datei- und Ordnerklassen nur über Methoden in diesen Sammlungen zu erstellen? Oder sollte ich Entwickler erlauben, Datei/Ordner ohne expliziten Verweis auf Service zu erstellen, indem Sie einen öffentlichen Konstruktor dafür machen? Ich denke nicht? Da zum Beispiel das Umbenennen einer Datei Methoden für den Dienst aufruft, der mit dem Netzwerk arbeitet. Sollte also jede Instanz von File, Item & Folder einen Verweis auf Service haben?

Diese Frage ist wahrscheinlich sehr chaotisch, aber ich weiß nicht gut, wie ich das erklären soll, tut mir leid. Im Allgemeinen frage ich, ob es eine gute Idee ist, eine benutzerdefinierte Sammlung von Datei-/Objekt-/Ordnertypen vorzunehmen oder ob es besser ist, generische Sammlungen verfügbar zu machen. Sollten diese exponierten Auflistungen auch schreibgeschützt sein und neue Dateien erstellen, indem Sie Service.CreateNewFile() anstelle von Service.Folders [0] .Add (New File()) aufrufen, wenn Sie wissen, was ich meine.

Vielen Dank für jeden Erfolg und/oder gute Links, die solche Entwicklungsmuster diskutieren.

Aaron

Antwort

0

Sie ein wenig von beidem verwenden könnte Ihr Ziel zu erreichen. Wenn Sie die Sammlungen als Eigenschaften verfügbar machen, erhalten Sie eine flexible und vertraute Benutzeroberfläche. Wenn Sie jedoch mehr Kontrolle über die Sammlungen haben, sie als schreibgeschützte Eigenschaften verfügbar machen und dann Methoden zum Hinzufügen, Entfernen usw. bereitstellen, erhalten Sie als Klassenentwickler mehr Kontrolle. Dies kann zu weniger Problemen führen, da der Zugriff auf die Sammlungen nur über eine begrenzte Schnittstelle erfolgt. Daher ist Ihr Kompromiss eine der Flexibilität gegenüber der Kontrolle. Beide Ansätze werden funktionieren.