Logik in Get-Teil der Eigenschaft. Gute Übung?

Es wird erwartet, dass Eigenschaftengetter schnell und idempotent sind (d.h. dort sollten keine destruktiven Aktionen ausgeführt werden). Obwohl es vollkommen in Ordnung ist, über eine Sammlung von Objekten im Speicher zu iterieren, würde ich es nicht empfehlen, irgendeine Art von schwerem Heben in den Teilen get oder set durchzuführen. Apropos Iteration, ich würde das Ergebnis trotzdem zwischenspeichern, um ein paar Millisekunden zu sparen.

Ja, es sei denn, es handelt sich um eine Operation, die möglicherweise Auswirkungen auf die Leistung hat. In diesem Fall sollten Sie stattdessen eine Methode verwenden (da es für den Endbenutzer intuitiver ist, dass eine Methode langsam ist, während eine Eigenschaft schnell ist)

Ich sage ja, aber versuche, die Ergebnisse von ListOfSomeClass.Sum (s = & gt; s.Totals) auf einer privaten Variablen zu speichern. Besonders, wenn Sie es mehr als einmal verwenden.

Ich sehe kein direktes Problem (es sei denn, die Liste ist ziemlich groß), aber ich würde persönlich die Methode myInstance.SomeList.Sum() verwenden, wenn möglich (.net & gt; = 2.0).

Für grundlegende Berechnungen aus Feldern oder anderen Eigenschaften in der Auflistung wäre es akzeptabel, dies innerhalb der Get-Eigenschaft zu tun. Wie alle anderen sagten, sollte wahre Logik nie im Getter gemacht werden.

Bitte ändern Sie den Getter zu diesem:

Sie verwenden bereits einen booleschen Ausdruck, ohne dass explizit oder falsch zurückgegeben werden muss

Eine komplexe Logik in Getter / Setter ist keine gute Übung. Ich empfehle, komplexe Logik zu separaten Methoden zu verschieben (wie GetSumOfXYZ ()) und Memoisierung in Eigenschaftenaccessoren zu verwenden.

Sie können komplexe Eigenschaften vermeiden, indem Sie ObjectDataProvider verwenden Sie definieren Methode, um einige Daten zu ziehen.

Ich mag Ihre Namenskonventionen und stimme der Verwendung von Inhalten wie Ihrem Beispiel in Eigenschaften-Gettern zu, wenn Sie eine API für die Bindung bereitstellen.

Ich stimme nicht mit dem Punkt überein, den andere gemacht haben, um Code in eine Methode zu verwandeln, nur weil er rechenintensiv ist - das ist kein Unterschied, den ich jemals machen würde, noch habe ich gehört, dass andere Leute meinen, dass es langsamer ist, in einer Methode zu sein als eine Eigenschaft.

Ich glaube, dass Eigenschaften auf dem Objekt, auf dem sie aufgerufen werden, frei von Nebenwirkungen sein sollten. Es ist viel schwieriger zu garantieren, dass sie keine Auswirkungen auf die weitere Umgebung haben - selbst eine relativ triviale Eigenschaft könnte Daten in den Speicher ziehen oder zumindest den Prozessor-Cache oder den vm-Zustand ändern.

Hängt davon ab ... wenn es sich um eine Domain-Entity handelt, dann wäre ich nicht dafür, komplexe Logik in einem Getter zu haben und vor allem nicht in einem Setter. Die Verwendung einer Methode (für mich) signalisiert einem Verbraucher der Entität, dass eine Operation ausgeführt wird, während ein Getter eine einfache Abfrage signalisiert.

Nun, wenn diese Logik in einem ViewModel war, dann denke ich, dass der Getter-Aspekt ein wenig mehr verzeihlich / erwartet ist.

Ich denke, dass es ein gewisses Maß an Logik gibt, das in Getters und Setter erwartet wird, sonst haben Sie nur eine Art verschachtelte Möglichkeit, Ihre Mitglieder öffentlich zu machen.

Ich würde vorsichtig sein, irgendeine Logik in den Getter einer Eigenschaft zu setzen. Je teurer es ist, desto gefährlicher ist es. Andere Entwickler erwarten, dass ein Getter sofort einen Wert zurückgibt, genau wie einen Wert aus einer Membervariablen. Ich habe viele Instanzen gesehen, in denen ein Entwickler eine Eigenschaft bei jeder Iteration einer Schleife verwendet und denkt, dass sie nur einen Wert zurückbekommen, während die Eigenschaft tatsächlich viel Arbeit macht. Dies kann zu einer erheblichen Verlangsamung der Codeausführung führen.