There are good reasons to not use use types like int
, string
, long
all over your code. Among other problems, this allows for stupid errors like
- using a key for one table in a query pertaining another table
- doing arithmetic on a key and winding up with a nonsense result
- confusing an index or other integral quantity with a key
and communicates very little information: Given int id
, what table does this refer to, what kind of entity does it signify? You need to encode this in parameter/variable/field/method names and the compiler won't help you with that.
Since it's likely those values will always be integers, using an integral type should be more efficient and put less load on the GC. But to prevent the aforementioned errors, you could use an (immutable, of course) struct
containing a single field. It doesn't need to support anything but a constructor and a getter for the id, that's enough to solve the above problems except in the few pieces of code that need the actual value of the key (to build a query, for example).
That said, using a proper ORM also solves these problems, with less work on your side. They have their own share of downsides, but they're really not that bad.