Da jeg gikk fra Delphi til C# ble jeg ikke overbegeistret over behovet for string.IsNullOrEmpty(myString) hver gang man skulle sjekke for tom streng. Jeg forstår at det kan bety en forskjell i den tekniske implementasjonen, men jeg forstår ikke hvorfor vi må brys med dette. Temaet har vært diskutert gang på gang, og det ser ut til at de fleste utviklere støtter idéen om at en tom streng faktisk ikke er det samme som en NULL-verdi.
jeg er uenig, av flere grunner:
- En streng er den eneste datatypen som faktisk har en naturlig NULL-verdi - en tom streng. Når du kan oppgi mellomnavn, betyr det "ingen verdi" om du lar feltet stå åpent.
- En stor databaseprodusent - Oracle - håndterer tom streng som NULL uten at dette er problematisk for en verden av RDBMS-utviklere, og programmeringsspråket Delphi Pascal (Versjon 2 ->) implementerer en tom streng som en NULL-peker under panseret uten at særlig mange utviklere har vært klar over det. jeg har aldri hørt noen klage på dette.
- For andre datatyper kan en brukerkontroll lett vise en NULL-verdi: En checkbox gråes ut, en radiogruppe har ingen selektert, et tomt numerisk felt. Hvordan ville du representert en NULL-verdie i en tekstboks ? Vise en grået <null> eller <empty> når verdien faktisk er NULL, og blank hvis verdien er en tom streng ? Lykke til med å forklare forskjellen til brukere...
Det eneste tilfellet hvor du faktisk må skille er i databasekolonner med UNIQUE constraint; Men her vil håndteringen av tom streng som NULL løse problemet.
EN slik under-panseret-håndtering som finnes i både Oracle og Delphi fører selvsagt med seg noen ekstra operasjoner her og der (=flere klokketikk), men jeg tror dette i de fleste tilfelle vil være fønskelig.
Mens vi snakker om rare tema i IT-verdenen - visste du at i Firebird database er 0<>-0 ?
Ha en god dag !