Der Zugriff auf nicht-öffentliche Mitglieder einer Klasse über eine Wrapper-Klasse („Accessor“), die [UnsafeAccessorAttribute] nutzt, wurde in .NET 8.0 eingeführt.

Nun funktioniert das auch mit generischen Parametern:

using System.Runtime.CompilerServices;
 
namespace NET9_Console.FCL90_UnsafeAccessor;
/// Der Zugriff auf nicht-öffentliche Mitglieder einer Klasse über eine Wrapper-Klasse, die [UnsafeAccessorAttribute] nutzt, wurde in .NET 8.0 eingeführt. Neu in .NET 9.0: Nun funktioniert dies auch mit generischen Parametern.
 
/// 

/// Eine Klasse mit zwei privaten Mitgliedern, die wir über UnsafeAccessorAttribute von Außen nutzen wollen
/// 
/// 
public class Printer
{
 private T _data = default;
 private void Print(PreTextType preText) { CUI.Green(preText.ToString()); Console.WriteLine(_data.ToString()); }
 public override string ToString()
 {
  return "Data=" + (_data?.ToString() ?? "(leer)");
 }
}
 
/// 

/// Accessor für Printer, um auf private Mitglieder zugreifen zu können
/// 
class PrinterAccessor
{
 [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_data")] // Zugriff auf das private Feld
 public extern static ref T GetSetPrivateField(Printer p);
 
 [UnsafeAccessor(UnsafeAccessorKind.Method, Name = "Print")] // Zugriff auf die private Methode
 public extern static void CallPrivatePrint(Printer p, PreTextType preText);
}
 
/// 
class Client
{
 public void Run()
 {
  CUI.Demo(nameof(FCL90_UnsafeAccessor));
 
  CUI.H2("Erzeuge das Objekt mit den privaten Mitgliedern");
  Printer printer = new Printer();
  Console.WriteLine("Vorher:\n" + printer.ToString());
 
  // Zugriff auf das Objekt via Accessor
  CUI.H2("Setzen eines privaten Feldes");
  ref Consultant data = ref PrinterAccessor.GetSetPrivateField(printer);
  data = new Consultant() { ID = 42, FullName = "Dr. Holger Schwichtenberg", PersonalWebsite = "www.dotnet-doktor.de", Address = new Address() { City = "Essen" }, Languages = ["C#", "VB.NET", "JavaScript/TypeScript"] };
  CUI.Success("Wert für Private Field gesetzt!");
  Console.WriteLine("Kontrolle über Zugriff auf das öffentliche ToString():\n" + printer.ToString());
 
  // Methode aufrufen
  CUI.H2("Aufruf einer privaten Methode mit generischen Parametern: CallPrivatePrint()");
  PrinterAccessor.CallPrivatePrint(printer, "Sie werden beraten von:");
 }
}

(rme)

Die meisten heute eingesetzten Softwaresysteme folgen klassischen Architekturmustern: Sie basieren auf einem relationalen Datenmodell, nutzen eine Schichtenarchitektur und stellen ihre Funktionen über eine REST-API oder eine Weboberfläche zur Verfügung. Dieses Vorgehen ist weit verbreitet, gut dokumentiert und in vielen Fällen auch ausreichend – zumindest auf den ersten Blick.

Doch mit zunehmender Komplexität treten wiederkehrende Probleme auf. Die Anwendungen werden schwer verständlich. Änderungen sind riskant. Die ursprüngliche Fachlichkeit ist im Code kaum noch zu erkennen. Warum ist das so?

Die Illusion einfacher Architektur

Das klassische CRUD-Modell (Create, Read, Update, Delete) ist intuitiv und direkt. Es orientiert sich an Tabellen und erlaubt einfache Operationen auf Daten. In kleinen Systemen oder Admin-Oberflächen ist das oft völlig ausreichend.

Doch sobald Anwendungen eine gewisse Komplexität erreichen – zum Beispiel durch Regeln, Zustandsübergänge oder Abläufe mit Nebenwirkungen –, stößt das Modell an Grenzen. CRUD speichert nur, was geändert wurde – nicht warum. Es macht keine Aussagen darüber, was passiert ist, sondern lediglich, wie der neue Zustand aussieht.

Und das ist ein Problem: Denn sobald Fachlichkeit nicht mehr direkt sichtbar ist, wird das System intransparent. Der Code beschreibt dann nicht mehr die Abläufe, sondern nur noch die Daten, die dabei herauskommen. Das führt dazu, dass die fachliche Bedeutung verloren geht.

Symptome einer überforderten Architektur

Wenn Architekturen die Fachlichkeit nicht abbilden, zeigt sich das in der Praxis sehr schnell:

• Die Systeme werden schwer verständlich – selbst für die, die sie entwickelt haben.
• Änderungen sind riskant, weil niemand sicher sagen kann, welche Auswirkungen sie haben.
• Workarounds häufen sich, weil sich neue Anforderungen nur schwer in das bestehende Modell integrieren lassen.
• Die Anwendung wird über die Zeit hinweg langsamer, fehleranfälliger und unflexibler.

Hinzu kommt: Klassische REST-APIs und synchroner Datenaustausch zwischen Systemen führen zu starker Kopplung. Systeme warten aufeinander. Fehler propagieren sich. Es entstehen fragile Ketten aus Aufrufen und Abhängigkeiten.

Wo der Denkfehler liegt

Der zentrale Denkfehler liegt in der Reihenfolge: Viele Architekturen beginnen beim Datenmodell. Es wird überlegt, welche Tabellen oder Dokumente gebraucht werden – und erst dann wird über Abläufe und Fachlogik nachgedacht.

Doch Fachlichkeit entsteht nicht aus Daten. Sie entsteht aus Vorgängen. Aus dem, was Menschen tun – aus Abläufen, Entscheidungen und Zustandsübergängen. Erst daraus ergeben sich die Daten.

Wenn man Fachlichkeit durch die Brille des Datenmodells betrachtet, zwingt man sie in ein statisches Schema. Das mag zu Beginn funktionieren, führt aber mittelfristig zu unflexiblen Systemen – weil das Modell sich nicht mehr natürlich mitentwickeln kann.

Ein besserer Ausgangspunkt

Statt mit Tabellen und APIs zu beginnen, sollte man bei den fachlichen Abläufen ansetzen: Was passiert in der Domäne? Welche Vorgänge treten auf? Welche Entscheidungen werden getroffen? Welche Konsequenzen hat das?

Diese Denkweise ist der Kern von Event-getriebener Architektur (Event-Driven Architecture, kurz EDA): Nicht Daten stehen im Zentrum, sondern Ereignisse. Dinge, die passiert sind. Dinge, die eine Bedeutung haben. Und Dinge, auf die andere reagieren können.

Das führt zu einer ganz anderen Struktur von Systemen: Sie werden modularer, entkoppelt, nachvollziehbar – und orientieren sich an dem, was das System eigentlich tun soll.

Was kommt als Nächstes?

Im nächsten Teil dieser Serie schauen wir uns die Bausteine einer Event-getriebenen Architektur genauer an: Commands, Events, Projections, Event-Streams und mehr. Damit wird sichtbar, wie aus fachlichen Vorgängen technische Strukturen entstehen – und wie daraus robuste, verständliche Systeme werden.

(mai)

Der Report zum ersten „State of Devs“ ist erschienen. Die Umfrage von Devographics bietet Einblicke in die Lebensumstände von Entwicklerinnen und Entwicklern weltweit. Es zeigt sich, dass sie zwar mit steigenden Gehältern rechnen können, aber dass das Einkommen dennoch der Hauptkritikpunkt am Job ist. Zufrieden sind viele mit dem Arbeitsumfeld und schätzen den positiven Umgang mit Kolleginnen und Kollegen.

Steigende Gehälter – aber auch sinkende

Innerhalb der letzten zwölf Monate vor der Umfrage konnte mehr als die Hälfte der Befragten (56 Prozent) einen Anstieg ihres Gehalts verzeichnen, insbesondere in Norwegen, wo dies auf 70 Prozent zutrifft. Hier gilt es allerdings zu bedenken, dass nur 67 Personen Norwegen als Wohnort angegeben haben. Ein gleichbleibendes Gehalt erhielten 35 Prozent der Studienteilnehmenden, während neun Prozent eine Gehaltsverringerung erlebten. In Deutschland erhielten 54 Prozent ein höheres Gehalt, 38 Prozent ein gleichbleibendes und sechs Prozent ein geringeres.

Dabei unterscheiden sich die durchschnittlichen Gehälter stark je nach Region: Im Spitzenreiter USA beträgt der Jahresbruttoverdienst im Schnitt rund 144.000 US-Dollar. Die DACH-Region belegt die Plätze 15, 12 und 3: In Deutschland erzielen die befragten Developer ein Durchschnittsgehalt von 79.000 US-Dollar, in Österreich 81.000 US-Dollar und in der Schweiz 111.000 US-Dollar.

Meistgenutzte Programmiersprachen: JavaScript und TypeScript

Auch in dieser Entwicklerumfrage durfte nicht fehlen, welche Programmiersprachen die Befragten nutzen (Mehrfachnennung möglich). Hier steht thematisch die Webentwicklung ganz oben, denn die Skala führen JavaScript (83 Prozent) und TypeScript (75 Prozent) an, gefolgt von CSS und HTML. Mit deutlichem Abstand belegen Python, PHP, Bash und Java die nachfolgenden Plätze. Beispielsweise nutzen Java lediglich 17 Prozent.

Zufriedene Developer in freundlicher Arbeitsumgebung

Die Arbeitszeit beträgt beim Großteil der Befragten 36 bis 40 Wochenstunden, und grundlegend sind die befragten Entwicklerinnen und Entwickler glücklich in ihrem Beruf: 44 Prozent sind „happy“ und 18 Prozent sogar „very happy“. Sehr unglücklich sind dagegen nur drei Prozent. Allerdings sind Einsteiger mit null bis vier Jahren Berufserfahrung im Schnitt unglücklicher als erfahrenere Developer, während ab zehn Jahren der durchschnittliche „Glückswert“ deutlich ansteigt.

Am meisten schätzen die Befragten an ihrem aktuellen Job die Beziehung zu ihren Kolleginnen und Kollegen: Diese Antwort gaben 71 Prozent. Darauf folgen die Work-Life-Balance (63 Prozent) und die Arbeitsbedingungen (60 Prozent). Das Gehalt nannten hier 44 Prozent. Auf der Liste der Schwierigkeiten am Arbeitsplatz steht das Gehalt dagegen ganz oben: 43 Prozent sind damit nicht zufrieden. Auch das Training und die Weiterbildungen empfinden 38 Prozent als unzureichend, und die Arbeitsinhalte können 34 Prozent nicht begeistern. Hierbei waren jeweils Mehrfachantworten möglich.

Demografie: Land, Geschlecht und Familienstatus

Die meisten Befragten stammen aus den USA (26 Prozent), gefolgt vom Vereinigten Königreich (9 Prozent) und Deutschland (8 Prozent). Devographics fiel auf, dass an dieser Studie mit 18 Prozent deutlich mehr Frauen teilnahmen als an ihren anderen Studien, wo der Anteil oft nur bei rund sechs Prozent liegt. 82 Prozent gaben an, männlich zu sein, drei Prozent nicht-binär und 0,3 Prozent sahen sich in den Auswahlmöglichkeiten nicht gelistet.

Darüber hinaus hat die Studie weitergehende Daten zum Privatleben erhoben: Demnach sind 75 Prozent der Befragten in einer Beziehung oder verheiratet. Die Mehrheit hat keine Kinder, und wenn, dann eher mit zunehmendem Alter, und meist eines oder zwei Kinder.

Detailliertere Antworten der Befragten

Die Ergebnisse der Umfrage sind auf der Website einsehbar. Neben den ausgewerteten Antworten können Interessierte jeweils Sprechblasen anklicken, um zu weiteren schriftlichen Ergänzungen der Teilnehmenden zu gelangen. Allerdings handelt es sich hierbei nur um den ersten Teil der Auswertung der gesamten Studie; ein zweiter soll folgen.

An der Umfrage „State of Devs“ von Devographics nahmen 8717 Personen im Zeitraum 15. April bis 15. Mai 2025 teil. Bei Devographics handelt es sich um einen Zusammenschluss von Beitragenden, Freiwilligen und Übersetzern rund um den Initiator Sacha Greif, der einst die Studie „State of JavaScript“ ins Leben rief. Die Studienmacher führen regelmäßig Umfragen durch, unter anderem auch „State of CSS“ und „State of React“.

(mai)