it-swarm.com.de

Was ist der Vorteil von reinen POCO-Modellen?

Was ist der Hauptvorteil von reinen POCO-Modellen? Ich verstehe, dass Modelle sauber und einfach sein sollten, aber ich neige dazu, die Wartung von untergeordneten Objekten innerhalb der Modellklassen beizubehalten. Zum Beispiel, wenn ich ein ClassA und ClassB wie folgt definiert habe:

public class ClassA
{
    public string MyProp { get; set; }
    public IEnumerable<ClassB> Children { get; }

    public void AddChild(ClassB newChild) { /*... */ }
    public void RemoveChild(ClassB child) { /* ... */ }
}

public class ClassB
{
    public string SomeProp { get; set; }
} 

Stimmt etwas von Natur aus nicht mit den Methoden zum Hinzufügen und Entfernen? Sollte ich stattdessen nur die Liste verfügbar machen und dem Client-Code erlauben, alles hinzuzufügen, was die Verantwortung für einfache Datenüberprüfungen wie nicht null übergibt, und nicht auf eine andere Klasse zu duplizieren?

Jede Hilfe wird geschätzt. Danke.

16
Jesse

Ihre beiden Fragen haben nichts miteinander zu tun.

Was ist der Vorteil von reinen POCO-Modellen?

Ein reiner POCO ist nicht abhängig von einem Unternehmensrahmen, einer Konvention, einem Ding oder eng mit einem Objekt verbunden, das ähnlich abhängig ist. Mit anderen Worten, die Welt kann sich um einen POCO herum komplett verändern und sie macht einfach weiter, was sie tut, ohne sich darum zu kümmern. Sie können es nicht brechen, indem Sie ein Framework aktualisieren, es in ein neues System verschieben oder es lustig betrachten. Es funktioniert einfach weiter. Die einzigen Abhängigkeiten sind die Dinge, nach denen explizit gefragt wird.

POCO ist nichts anderes als die POJO-Idee. Das J wurde in ein C geändert, weil die Leute dich lustig ansehen, wenn du ein Konzept erklärst, dessen Name Java) enthält, wenn diese Leute C # verwenden. Die Idee ist nicht sprachabhängig. Sie könnten habe es einfach Plain Old Objects genannt. Aber wer möchte damit prahlen, POO zu verwenden?

Ich werde Fowler die Ursprünge erklären lassen:

Der Begriff wurde geprägt, als Rebecca Parsons, Josh MacKenzie und ich uns auf einer Konferenz im September 2000 auf einen Vortrag vorbereiteten. In dem Vortrag wiesen wir auf die vielen Vorteile der Kodierung von Geschäftslogik in reguläres Java) hin Wir fragten uns, warum die Leute so dagegen waren, normale Objekte in ihren Systemen zu verwenden, und kamen zu dem Schluss, dass einfache Objekte keinen ausgefallenen Namen hatten. Also gaben wir ihnen einen, und er hat sich sehr gut durchgesetzt.

martinfowler.com: POJO

Was Ihre andere Frage betrifft:

Stimmt etwas von Natur aus nicht mit den Methoden zum Hinzufügen und Entfernen?

Ich mag es nicht, wenn A direkt über B Bescheid weiß. Aber das ist ein DIP Ding, kein POJO Ding.

44
candied_orange

Mit Hinzufügen und Entfernen implementieren Sie Collection<T> - Funktionen. Fragen Sie sich, warum Sie IEnumerable<T> Anstelle von List<T> Oder einer anderen veränderlichen Klasse verwenden? Anscheinend liegt es nicht daran, dass Ihre Sammlung schreibgeschützt sein sollte.

Der einzige Grund, an den ich denken kann, ist, dass Sie steuern möchten, welche Zugriffsmethoden Sie veröffentlichen möchten. In diesem Fall wäre es besser, eine eigene Auflistungsklasse zu erstellen, eine Liste zu kapseln, Ihre Auswahlmethoden zu implementieren und IEnumerable<T> Zu implementieren. Verwenden Sie dies dann anstelle von IEnumerable<T> Für den Typ Ihrer Kindersammlung.

Aber es scheint mir, List<ClassB> Würde Ihnen wahrscheinlich nur gute Dienste leisten.

3
Martin Maat

Was fügt AddChild hinzu und RemoveChild entfernt von? Wenn es aus der Datenbank (oder einem Persistenzspeicher jeglicher Art) stammt, haben Sie eine Art aktiven Datensatz. Nicht unbedingt immer eine schlechte Sache, aber es bringt Sie definitiv dazu, sich Gedanken über Frameworks, Konventionen, Abhängigkeiten usw. machen zu müssen, wie @CandiedOrange erwähnt.

Was wäre der Grund, um eine Abhängigkeit von Klasse A zu Klasse B (oder zumindest Schnittstelle B) zu vermeiden, wenn sich alle in derselben Anwendung befinden? In der realen Domäne, die Ihre Anwendung modelliert, hängen die Dinge voneinander ab. Reale Objekte haben Sammlungen anderer Objekte, die ihnen "gehören". Es ist völlig angemessen, diese Beziehungen in Ihrem Code darzustellen.

Der einzige Grund, warum es noch etwas komplizierter wird, ist, dass Sie anscheinend genau verwalten müssen, wie eine Klasse B mit Klasse A assoziiert und von dieser getrennt wird. Sie müssen also ein wenig Verhalten implementieren. Sie können es entweder innerhalb der Klasse implementieren (was völlig "legal" ist; siehe https://stackoverflow.com/a/725365/44586 ), oder Sie können eine separate Klasse haben, die enthält dieses Verhalten. Tun Sie, was für Ihre individuellen Umstände am sinnvollsten ist.

In jedem Fall ist POJO/POCO wirklich nur OOP wie es sein sollte, schmucklos und unbelastet. Befolgen Sie die Prinzipien OOP und Sie sind in Sicherheit).

0
John M Gant