Normalt brukar man rekommendera att man använder propertyn och inte fältet bakom, i ditt fall alltså "Blabla" och inte "blabla". Har man någon form av valideringskod i settern vill man inte av misstag sätta den till något trasigt värde (det kan bli marginellt långsammare, men om JITen är lite smart borde triviala get/set-metoder inlinas). I C# 3 finns det ju till och med stöd för att slippa ange det bakomliggande fältet:
public string Blabla { get; set; }
Gör man på det viset behöver man inte fundera över vad man ska använda :)
red. Klargörande av terminologi: I ditt fall är "blabla" ett fält och "Blabla" är en property. En property har egentligen inget eget värde, utan är ett standardiserat sätt att ange metoder som hämtar och/eller sätter värden (antingen direkt på fält eller på andra properties). I ditt fall blir propertyn Blabla två metoder:
public string get_Blabla { return blabla; }
public void set_Blabla(string value) { blabla = value; }
Jag vet inte om jag gillar "auto-properties", i många fall vill man ändå ha funktionalitet i propertyn som t.ex. ett OnPropertyChanged("Name") anrop, lazyloading funktionalitet och lite annat smått och gått. Och om man då blir sittandes med några auto-properties och några vanliga properties så blir det inte konsekvent och sådant tycker jag inte är så bra.
Har man saker grupperat så tycker jag inte det gör så mycket med de vanliga properties som finns.
253 ms totalt · 4 externa anrop · v20260731065814-full.6fe65c25
