Wir haben eine Menge Code, der über " Ids " von Datenzeilen; diese sind meist Ints oder Guids. Ich könnte diesen Code sicherer machen, indem ich eine andere Struktur für die ID jeder Datenbanktabelle. Dann hilft die Typüberprüfung, Fälle zu finden, in denen die falsche ID übergeben wird.
Z.B. hat die Tabelle Person eine Spalte namens PersonId und wir haben Code wie:
DeletePerson(int personId)
DeleteCar(int carId)
Wäre es besser, sie zu haben:
struct PersonId
{
private int id;
// GetHashCode etc....
}
DeletePerson(PersionId persionId)
DeleteCar(CarId carId)
-
Hat jemand Erfahrungen aus dem wirklichen Leben Erfahrungen damit?
-
Ist es den Aufwand wert?
-
Oder mehr Schmerz als es wert ist?
(Das würde es auch einfacher machen, den Datentyp des Primärschlüssels in der Datenbank zu ändern, deshalb habe ich mir diese Idee überhaupt erst ausgedacht)
Bitte sagen Sie nicht, dass Sie ein ORM oder eine andere große Änderung am Systemdesign verwenden sollen, denn ich weiß, dass ein ORM eine bessere Option wäre, aber das liegt derzeit nicht in meiner Macht. Ich kann jedoch kleinere Änderungen wie die oben genannten an dem Modul vornehmen, an dem ich derzeit arbeite.
Aktualisierung: Beachten Sie, dass es sich hier nicht um eine Webanwendung handelt und die Ids im Speicher gehalten und mit WCF weitergegeben werden, so dass am Rand keine Konvertierung in/aus Strings erfolgt. Es gibt keinen Grund, warum die WCF-Schnittstelle nicht den Typ PersonId usw. verwenden kann. Der PersonId-Typ usw. könnte sogar im WPF/Winforms UI-Code verwendet werden.
Die einzige inhärente "untypisiert" Teil des Systems ist die Datenbank.
Es scheint eine Kosten-Nutzen-Abwägung zu sein, ob man Zeit damit verbringt, Code zu schreiben, den der Compiler besser überprüfen kann, oder ob man die Zeit damit verbringt, mehr Unit-Tests zu schreiben. Ich entscheide mich eher dafür, die Zeit für Tests zu verwenden, da ich zumindest einige Unit-Tests in der Codebasis sehen möchte.