Laden...

Gibt es eine Möglichkeit den Readonly Modifier zu umgehen?

Erstellt von Frokuss vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.168 Views
F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren
Gibt es eine Möglichkeit den Readonly Modifier zu umgehen?

Wunderschönen 😃

Also, ich wollte mal fragen ob es eine Möglichkeit den readonly Modifizierer zu umgehen gibt? Der Hintergrund ist, dass ich einen eigenen Control erzeugt habe der als Attribut: readonly int id; hat. Jetzt möchte ich allerdings dynamisch einen solchen Control erzeugen, ohne dass mir die ID bereits bekannt ist... Die ID muss nämlich (theoretisch - habe noch keine DB-Anbindung) vom Server kommen.

Ich vermute dass es nicht geht... Aber die hoffnung stirbt ja bekanntlich zu letzt...

Gruß Frokuss

T
2.219 Beiträge seit 2008
vor 4 Jahren

Wird nicht funktionieren, weil sonst auch der readonly modifier sinnlos wäre.
Wenn du das Control ändern kannst, dann entferne den modifier und arbeite sauber mit der ID.
Z.b. wäre eine Anpassung der ID Property mit einem public getter und einem private setter.
Dann musst du nur beim erstellen des Controls die ID an den Konstruktor mitgeben und dort einmalig die ID setzen.

Wenn du es nicht ändern kannst, musst du schauen ob du das Problem anders lösen kann.

Muss die ID ein int sein?
Wenn möglich nimm Guid, wenn es eine eindeutige ID sein sollte, oder string wenn du auch andere Werte/Bezeichnungen verwenden willst.
Fast alle Controls nutzen Strings für ID im Web und Desktop Bereich in .NET

Nachtrag:
Wie genau soll der Server die Daten liefern?
Wenn es sich bei der Anwendung um eine UI für den Endbenutzer handelt, lädst du die Daten hoffentlich nicht direkt über die DB sondern von z.B. eine API in einem Web was dann auf die DB zugreift.
Somit bleibt deine DB sicher vor unbefugten Zugriffen 😉

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 4 Jahren

Wenn Du sowas umgehen musst, dann hast Du ganz klassisch einen großen, in diesem Fall sogar einen schwerwiegenden Designfehler in Deiner Software Architektur 😉

Wenn möglich nimm Guid, wenn es eine eindeutige ID sein sollte,

Nein. Das ist so pauschal ausgedrückt eine ganz ganz unglückliche Idee.
Eine Id sollte immer das sein, was sie auch ausdrückt - und das ist ganz bestimmt nicht immer eine Guid.

Vor allem so pauschal ausgedrückt spricht nichts, aber auch gar nichts gegen Int.
Ich bin prinzipiell auch ein Fan von Guid / UUID - aber Guid bringt immer eine gewisse Komplexität rein.
Die prinzipiellen Nachteile von Int in Sachen DB-Skalierung (und das ist meist der einzig relevante Nachteil) spielt in 99,9999% der Projekte überhaupt keine Rolle.
-> KISS-Prinzip

Fast alle Controls nutzen Strings für ID im Web und Desktop Bereich in .NET

Nö.

F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren

@T-Virus:
Das mit dem private set ist mal ne super geile Idee 😄 Habe ich noch nie vorher drüber nachgedacht 😄

@Abt:
warum ist das ein Fehler in der Architektur? Ich wolle ja nur verhindern, dass die ID sich grundlos ändern lässt. Jetzt habe ich halt genau einen einzogen Fall, in dem ich ihn ändern muss, da mir die ID noch nicht zur Verfügung steht. Ich habe damit die Möglichkeit wie sie mir T-Virus gezeigt hat, oder die Möglichkeit über einen "temporären"-Controll, der mit weniger auskommt und dann ersetzt wird...

Die ID muss nicht zwingend eine Zahl sein. Allerdings kommen die Daten (irgendwann mal) aus der Datenbank. Dort haben die Daten dann eine ID, die sich mit dem in meinem Controll decken würde. Sprich ändere ich den Text in meinem Controll, muss der Text auch in der DB geändert werden (und irgendwann mal im Jahr 3000 auch auf anderen Geräten). Dafür brauche ich die ID.

Ich habe jetzt das mal draus gemacht. Ich weis, ist natürlich total bescheuert, dass in 2 Methoden zu machen - will aber erzwingen, dass die ID nur in ausnahmefällen geändert wird.

        public int ID {
            get { return id; }
            private set { id = value; }
        }

        public int ___ID {
            set { 
                if(id == 0)
                    ID = value;
            }
        }

Aber mal ne Frage... welchen Wert hat denn ein int, wenn ich ihm noch keinen Wert zugewiesen habe? Also null ist es nicht... (int a, b, c;)

Ich kann meinen Anwendungsfall zwar erläutern - dann wäre dies aber wohl eher in der Rubrik WinForms einzuordnen...

Gruß Frokuss

Nachtrag: Darüber habe ich mir noch keine gedanken gemacht XD aber ich hätte sie aus einer DB gezogen... Ja, es handelt sich um eine UI für den Endnutzer. Also alles rund um den Server habe ich noch gar nicht gemacht... nichts!

T
2.219 Beiträge seit 2008
vor 4 Jahren

@Abt
Also bei ASP .NET mit Web Forms und WinForms sowie auch bei WPF sind meins Wissens nach alle Controls mit einer ID Property vom Typ String vorhanden.
Klar gibt es Aussahmen aber bei diesen würde was anderes als String kaum Sinn machen um diese eben per ID anzusprechen.

@Frokuss
int ist ein Werte Type und kann nie null sein, dies gilt nur für Referenztypen.
Nur wenn du ein Nullable Int hast, kann dies auch Null sein.
Ansonsten kannst du für die default Werte auch gerne in die Doku schauen.
Bei int ist der Default Wert immer 0.

Deine Umsetzung mit zwei Properties sieht sehr abenteuerlich aus.
Warum setzt du dann die Logik nicht im setter von ID ein und setzt den Wert dann nur wenn die interne Member Variable 0 ist?
Dann brauchst du keine zwei setter und dürftest immer nur einmal den Wert setzen.

Nachtrag:
Dann solltest du dir darum Gedanken machen.
Wenn die Anwendung z.B. über das Internet auf deine Datenbank zugreifen soll, dann wäre dies fatal diese direkt darauf zugreifen zu lassen.
Dafür schaltet man einen Webservice, der dann die API zum Datenaustausch mit der Anwendung anbietet.
Die Anwendung selbst bekommt dann keinen direkten Zugriff.
Die DB sollte dann auch sicher abgeschottet werden, damit kein direkter Zugriff darauf möglich ist.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren

Ja, du hast recht... Ich neige manchmal die einfachsten Sachen unnötig kompliziert zu machen. Aber ist ja fix geändert...

Also vom Gedanken her wollte ich auf jeden Fall eine Server-Anwendung erstellen, die den alleinigen Zugriff auf die Datenbank hat. Diese verarbeitet dann die Komandos der ganzen Clients...

Gruß Frokuss

16.807 Beiträge seit 2008
vor 4 Jahren

Also bei ASP .NET mit Web Forms und WinForms sowie auch bei WPF sind meins Wissens nach alle Controls mit einer ID Property vom Typ String vorhanden.

Ist das gerade Ironie, oder verwendest Du wirklich obsolete, uralte Technologien als Beispiel 😃

Davon abgesehen kannst Du basierend auf den Informationen hier im Thread überhaupt keine Aussage machen, welche Anforderungen die Id hat.
Ob es ein Control ist, ist total irrelevant.

Er schreibt doch sogar, dass die Id/das Control aus einer Datenbank kommt - hat also nicht unbedingt mit der UI, mit denen UI-Frameworks arbeiten zutun.

Die DB sollte dann auch sicher abgeschottet werden, damit kein direkter Zugriff darauf möglich ist.

Auch hier kennst Du die Gegebenheiten nicht, sofern wir die Informationen nur hier aus dem Thread haben.
Ja, ein Service macht oft sinn - aber nicht immer.

warum ist das ein Fehler in der Architektur? Ich wolle ja nur verhindern, dass die ID sich grundlos ändern lässt.

Die ID soll wohl bewusst readonly sein; willst aber eine Hintertür haben, um sie doch ändern zu können.
Da klingeln alle Alarmglocken, dass hier was nicht stimmen kann 😃
Und natürlich gibt es bei readonly nicht wirklich eine Hintertür - und das ist auch gut so.

Solche "Ausnahmefälle" muss Deine Logik und Dein Konzept abdecken - nicht der C# Sprachsyntax.

Also alles rund um den Server habe ich noch gar nicht gemacht... nichts!

... wäre wohl besser gewesen, wenn Du Dir vor dem Programmieren ein Konzept gemacht hättest. 😃
Empfehl Dir Deine Herangehenweise hier etwas zu überdenken.

Die Gefahr, dass Du hier viel geschriebenen Quellecode wegwerfen darfst, weil Dir ein Konzept fehlt, ist immens - und im Allgemeinen leider auch sehr wahrscheinlich.