Ist es eine gute Praxis, Logik in Eigenschaften zu implementieren

Question

wir verwenden ASP.NET mit C# und basierend auf Open-Source-Projekte/Artikel, die ich durchgereicht habe, fand ich viele Eigenschaften einschließlich einer Logik aber wenn ich so tat die Team- Leiter sagte mir, es ist überhaupt nicht gut, Logik in Eigenschaften zu platzieren, sondern die Logik durch Methoden aufrufen ...

ist das wirklich schlimm? und warum nicht Logik in den Eigenschaften verwenden?

Dank,

Answer 1

Der Zugriff auf die Eigenschaften wird sofort erwartet (keine langen Wartezeiten), konsistent (keine Änderung der Werte) und sicher (keine Ausnahmen). Wenn Sie diese Garantien geben können, denke ich, Logik in Eigenschaften zu setzen ist in Ordnung.

Answer 2

Es ist in Ordnung einige Logik in Eigenschaften haben. Zum Beispiel sind die Validierung von Argumenten in Setter und die Lazy-Berechnung in Gettern ziemlich üblich.

Es ist in der Regel eine schlechte Idee für eine Eigenschaft Zugriff auf etwas teures wie eine Datenbank-Aufruf jedoch zu tun. Entwickler neigen dazu, anzunehmen, dass Immobilien relativ günstig bewertet werden können.

Es ist ein Urteilsspruch am Ende - aber ich lehne sicher den Vorschlag ab, dass Eigenschaften immer nur trivial sein sollten, soweit sie mit automatischen Eigenschaften implementiert werden könnten.

Answer 3

. Sie sind nur Abkürzungen für Getter/Setter. Jede Logik, die in einem Getter/Setter gültig wäre, ist vernünftig, um eine Eigenschaft einzufügen. Jede Logik, die Sie normalerweise nicht in einen Getter/Setter einfügen würden, wäre unangemessen, um eine Eigenschaft einzufügen. Wenn Sie (als Konsument der Klasse) nicht wirklich erwarten können, dass ein Eigenschaftswert festgelegt wird, oder noch schlimmer, wenn ein Eigenschaftswert dazu führt, dass ein Verhalten stattfindet, dann gehört diese Logik wahrscheinlich woanders hin. Mit anderen Worten, die Logik sollte verwandt und konsistent sein mit dem Abrufen oder Festlegen der Eigenschaft.

aus dem verlinkten Artikel Zitiert oben:

Eigenschaften Mitglieder sind, die einen flexiblen Mechanismus zum Lesen zur Verfügung stellen, schreiben oder die Werte der privaten Felder berechnen. Eigenschaften können verwendet werden, als ob sie öffentliche Datenelemente sind, aber sie sind tatsächlich spezielle Methoden namens Accessoren. Dies ermöglicht den einfachen Zugriff auf die Daten und bietet gleichzeitig die Sicherheit und Flexibilität der Methoden .

Answer 4

Eine allgemeine Antwort gilt hier: Es hängt davon ab.

Im Allgemeinen ist es keine gute Idee, Geschäft Logik in Getter und Setter zu implementieren. Wenn Ihr Objekt ein einfaches DTO (Datenübertragungsobjekt) ist, würde dies die Einzelverantwortlichkeit verletzen.

Allerdings finden sich in den Eigenschaften oft Status-Tracking-Logik und andere Haushaltsfunktionen. Entity Framework 4 Self-Tracking-Entitäten verfügen z. B. in jedem primitiven Property-Setter über eine Statusverwaltungslogik, um die Verfolgung zu ermöglichen.

Eine Alternative zur Logik in Eigenschaften ist die aspektorientierte Programmierung (AOP). Mit AOP können Sie Logik zwischen Objekten und dem Hosting-Prozess "injizieren".Der Zugriff auf Objekte kann "abgefangen" werden und bedingt gehandhabt werden.

Answer 5

Normalerweise betrifft eine Eigenschaft nur 1 Variable, da sie hauptsächlich für diesen Zweck erstellt wurde. Aber irgendwann wollen Sie eine höhere Eigenschaft, die nicht nur eine 1-zu-1-Variable ist. In diesem Fall ist es normal, dass es Code enthält. Aber Sie müssen bedenken, dass eine Eigenschaft nicht als eine Funktion verwendet werden soll. Wenn Sie eine Funktion aufrufen, wissen Sie, dass sie etwas verarbeitet. Wenn Sie eine Eigenschaft aufrufen, erwarten Sie, dass sie schnell ist.

Aber schließlich ist es eine Frage der Vorlieben, und wie Kodierung Standard, nach dem, was Ihr Vorgesetzter Ihnen sagt, ist in Ihrem Ermessen. Es ist also nicht schlecht und hängt von deinem Urteil ab.

Answer 6

Meiner Meinung nach ist Geschäftslogik in Setter/Getter nur in bestimmten Situationen erlaubt. Zum Beispiel: Es ist erlaubt, eine Logik zu setzen, die für die Validierung der Eingabe verantwortlich ist, da Setter für den Erhalt des Objektstatus verantwortlich sind, so dass der Status nicht verletzt werden sollte. Daher sollten Sie diese Geschäftslogik auf den kleinsten Teil des Codes reduzieren, der nur für ein Thema verantwortlich ist.

Die andere Sache ist, dass Ihre Klasse (in der besten Situation) POCO sein sollte. Warum? Weil es wiederverwendbar sein sollte und wenn die Klasse Logik in Eigenschaften enthält, kann die Wiederverwendbarkeit einfach blockiert werden. Denken Sie, dass Sie SqlServerPerson mit einigen SQLServer-Validierung in Eigenschaften haben, dann kann es schwierig sein, es durch zum Beispiel NHibernatePerson zu ersetzen, wenn Sie den ORM/DB-Zugriff ändern.

Answer 7

Das Platzieren von Geschäftslogik in einem Setter kann Probleme verursachen, wenn Sie Objekte mit JSon, XML oder einem ORM serialisieren/deserialisieren müssen. Ein Beispiel hierfür ist die Verwendung eines NoSql-Datenspeichers wie einer Dokumentendatenbank oder eines ORM. Einige von diesen (z. B. NHibernate) können so konfiguriert werden, dass sie auf Unterstützungsfelder anstelle des Setter zugreifen.

Ich finde, dass die Verwendung eines öffentlichen Getter und Private Setter zusammen mit einer Methode, um den Wert mit zusätzlicher Logik als erforderlich festzulegen ist ein guter Ansatz. Die meisten Serializer können auf den privaten Setter zugreifen, sodass Sie eine genaue Darstellung des persistenten Objekts erhalten, ohne versehentlich eine Logik auszulösen, die bei der Deserialisierung möglicherweise Werte falsch ändert.

Wenn Sie jedoch nicht glauben, dass jemals eine Serialisierung/Deserialisierung erforderlich sein wird, sollte dies kein Problem sein.

Answer 8

Meiner Meinung nach ist das absolut in Ordnung. So wie ich das sehe, ist die einzige Rechtfertigung dafür, dass Eigenschaften in erster Linie ein Sprachfeature sind, darin zu suchen, dass sie Logik in sich tragen können. Andernfalls können Sie auch direkten Zugriff auf die zugrunde liegenden Datenelemente zulassen.