Gibt es einen Grund, automatisch implementierte Eigenschaften gegenüber manuell implementierten Eigenschaften zu verwenden?

Ich verstehe die Vorteile von EIGENSCHAFTEN über FELDER, aber ich habe den Eindruck, dass die Verwendung von AUTO-implementierten Eigenschaften gegenüber MANUAL implementierten Eigenschaften keinen wirklichen Vorteil bietet, außer dass der Code etwas übersichtlicher gestaltet wird.

Ich fühle mich viel wohler mit:

private string _postalCode; public string PostalCode { get { return _postalCode; } set { _postalCode = value; } } 

Anstatt von:

 public string PostalCode { get; set; } 

Vor allem, weil, wenn ich jemals irgendeine Art von benutzerdefinierter Implementierung von get und set machen möchte, ich meine eigene Eigenschaft sowieso von einem privaten Feld unterstützt erstellen muss. Warum also nicht von Anfang an in die Kugel beißen und allen Eigenschaften diese Flexibilität geben, aus Konsistenzgründen? Dies erfordert keine zusätzliche Sekunde, da Sie in Visual Studio lediglich auf den Namen Ihres privaten Felds klicken und Strg + E drücken müssen. Und wenn ich es manuell mache, dann habe ich am Ende Inkonsistenzen, in denen einige manuell erstellte öffentliche Eigenschaften durch private Felder und einige automatisch implementierte Eigenschaften unterstützt werden. Ich fühle mich viel besser, weil es rundherum konsistent ist, entweder ganz automatisch oder ganz manuell.

Ist das nur ich? Fehle ich etwas? Täusche ich mich über etwas? Betone ich zu viel Konsistenz? Ich kann immer legitime Diskussionen über C # -Features finden, und es gibt fast immer Vor- und Nachteile für alles, aber in diesem Fall konnte ich wirklich niemanden finden, der die Verwendung von automatisch implementierten Eigenschaften empfohlen hat.

    Es gewährt Ihnen nichts Besonderes, außer dass es prägnant ist. Wenn Sie die ausführlichere Syntax bevorzugen, dann verwenden Sie diese auf jeden Fall.

    Ein Vorteil der Verwendung von Auto Requisiten ist, dass es Sie möglicherweise davor bewahren kann, einen albernen Codierungserrors zu machen, wie versehentlich die falsche private Variable einer Eigenschaft zuzuweisen. Vertrau mir, ich habe es schon mal gemacht!

    Dein Punkt über Autostützen, die nicht sehr flexibel sind, ist ein guter. Die einzige Flexibilität, die Sie haben, besteht darin, entweder private get oder private set zu verwenden, um den scope zu begrenzen. Wenn Ihre Getter oder Setter eine gewisse Komplexität haben, sind die automatischen Requisiten keine brauchbare Option mehr.

    Für automatisch implementierte Eigenschaften wird nicht garantiert, dass der Name des Backing-Felds zwischen den Builds beibehalten wird. Daher ist es theoretisch möglich, dass das Serialisieren eines Objekts in einer Version einer Assembly und das anschließende erneute Serialisieren desselben Objekts in einer anderen Assembly zu Änderungen führen kann.

    Dies ist sehr unwahrscheinlich, aber es ist ein berechtigtes Problem, wenn Sie versuchen, die Möglichkeit zu erhalten, die Version Ihrer Assembly für neuere Versionen zu “auslagern”.

    Durch die Verwendung von manuell implementierten Eigenschaften wird garantiert, dass sich das Hintergrundfeld niemals ändert (es sei denn, Sie ändern es speziell).

    Abgesehen von diesem winzigen Unterschied ist eine automatische Eigenschaft eine normale Eigenschaft, die automatisch mit einem Hintergrundfeld implementiert wird.

    Es gibt Leute, die denken, dass automatische Eigenschaften etwas Böses sein können, aber abgesehen davon sind sie nur syntaktischer Zucker. Sie erhalten nichts, wenn Sie sie verwenden, abgesehen davon, dass Sie ein paar Zeilen Code speichern, und Sie können potenziell mehr Arbeit für sich selbst schaffen (indem Sie sie später manuell implementieren, weil Sie etwas überprüfen oder ein Ereignis auslösen möchten). Konsistenz ist sehr nützlich beim Programmieren (imho).

    Eines der Dinge, über die Sie die Kontrolle verlieren, ist die Möglichkeit, das Backing-Feld als NonSerialized anzugeben, aber es ist einfach, in diesem Fall ein Backing-Feld für die Eigenschaft zu erstellen.

    Vergessen: Wenn Sie oder ein Produkt, das Sie verwenden, eine Reflektion über die Mitglieder durchführt (z. B. WCF), wird anstelle des von Ihnen erstellten “hübschen” Hintergrundfelds der Name des beschädigten Hintergrundfelds angezeigt.

    Dies kann sehr wichtig sein, wenn Sie zuvor Zugriff auf den Service bereitgestellt haben oder wenn Sie auf der Empfängerseite in dieselbe classnstruktur deserialisieren (dh an beiden Enden der WCF-Pipe werden die gleichen classn verwendet). In diesem Fall können Sie die Deserialisierung nicht unbedingt durchführen, da Sie sicherstellen können, dass der Name des Backing-Felds identisch ist, es sei denn, Sie teilen dieselbe DLL im Gegensatz zum Quellcode.

    Ein wenig mehr Klarheit: Angenommen, Sie haben einen Webdienst, der einige Ihrer Geschäftsobjekte über WCF einem von Ihnen erstellten Silverlight-Client zur Verfügung stellt. Um Ihre Geschäftslogik wiederzuverwenden, fügt Ihr Silverlight-Client Verweise auf den Quellcode für Ihre Geschäftsobjekte hinzu. Wenn Sie über automatisch implementierte Eigenschaften verfügen, haben Sie keine Kontrolle über den Namen des Backing-Felds. Da WCF die Member und nicht die Eigenschaften serialisiert, können Sie nicht sicher sein, dass das Objekt, das vom WCF-Dienst an silverlight übertragen wird, korrekt deserialisiert wird, da die Namen der Backing-Felder höchstwahrscheinlich nicht übereinstimmen.

    Ich weiß nicht über alle anderen, aber ich neige dazu, einen Moment innezuhalten, um darüber nachzudenken, wie ich meine Variablen und functionen benennen soll, damit andere meinen Code verstehen können.

    Wenn ich also automatisch implementierte Eigenschaften verwende, muss ich nur einmal pausieren .

    Wenn ich ein Unterstützungsfeld brauche, muss ich zweimal pausieren , damit es die Entwicklung etwas verlangsamt 🙂

    So wie ich es mache ist:

    1. Machen Sie es am Anfang zu einer privaten Variable
    2. Ändern Sie es bei Bedarf automatisch.
    3. Ändere es in das Hintergrundfeld, wenn ich Code in get oder set benötige.

    Es ist nichts falsch, wenn unterschiedliche Eigenschaften einer class unterschiedlich dargestellt werden.

    Einer der Vorteile, den ich bei der Verwendung von Auto-Eigenschaften sehe, ist: Beim Debuggen der Anwendung wird es nicht in den unnötigen Get / Set-Abschnitt gelangen . Ich weiß, dass wir das vermeiden können, indem wir Debugger Attribute verwenden oder Step over; Es passiert jedoch am häufigsten, wenn Sie eine große Anwendung debuggen.