Quais são as desvantagens de mapear identificadores integrais para enumerações?

Eu estive pensando em criar tipos personalizados para identificadores como este:

public enum CustomerId : int { /* intentionally empty */ }
public enum OrderId : int { }
public enum ProductId : int { }

Minha principal motivação para isso é evitar o tipo de bug em que você acidentalmente passa um orderItemId para uma função que esperava um orderItemDetailId.

Parece que as enums funcionam perfeitamente com tudo o que eu gostaria de usar em um aplicativo Web .NET típico:

• O roteamento MVC funciona bem
• A serialização JSON funciona bem
• Cada ORM em que consigo pensar funciona bem

Então agora estou me perguntando: "por que não devo fazer isso?" Estas são as únicas desvantagens em que consigo pensar:

• Pode confundir outros desenvolvedores
• Introduz inconsistência no seu sistema se você tiver algum identificador não integral.
• Pode exigir elenco extra, como (CustomerId)42. Mas não acho que isso seja um problema, pois o roteamento ORM e MVC normalmente estará entregando valores do tipo enum diretamente.

Então, minha pergunta é: o que estou perdendo? Esta é provavelmente uma má ideia, mas por quê?

É uma ótima idéia criar um tipo para cada tipo de identificador, principalmente pelos motivos que você declarou. Eu não faria isso implementando o tipo como enum, porque torná-lo uma estrutura ou classe adequada oferece mais opções:

• Você pode adicionar conversão implícita em int. Quando você pensa sobre isso, é a outra direção, int -> CustomerId, que é a problemática que merece confirmação explícita do consumidor.
• Você pode adicionar regras de negócios que especificam quais identificadores são aceitáveis ​​e quais não são. Não se trata apenas de uma verificação fraca se o int é positivo: às vezes, a lista de todos os IDs possíveis é mantida no banco de dados, mas muda apenas durante a implantação. Em seguida, você pode facilmente verificar se o ID fornecido existe em relação ao resultado em cache da consulta adequada. Dessa forma, você pode garantir que seu aplicativo falhe rapidamente na presença de dados inválidos.
• Os métodos no identificador podem ajudá-lo a fazer verificações caras da existência do banco de dados ou a obter o objeto de entidade / domínio correspondente.

Você pode ler sobre como implementar isso no artigo C # funcional: obsessão primitiva .

É um truque inteligente, mas ainda assim um abuso que abusa de um recurso para algo que não é o objetivo pretendido. Os hackers têm um custo em manutenção, portanto, não é suficiente que você não encontre outras desvantagens, também precisa ter benefícios significativos em comparação com a maneira mais idiomática de resolver o mesmo problema.

A maneira idiomática seria criar um tipo de wrapper ou estrutura com um único campo. Isso fornecerá o mesmo tipo de segurança de maneira mais explícita e idiomática. Embora sua proposta seja reconhecidamente inteligente, não vejo vantagens significativas no uso de tipos de wrapper.

Do meu ponto de vista, a ideia é boa. A intenção de fornecer tipos diferentes para classes de identificadores não relacionados e, de outro modo, expressar semântica por meio de tipos e deixar que o compilador verifique isso, é boa.

Não sei como ele funciona no .NET em termos de desempenho, por exemplo, os valores de enum estão necessariamente em caixas. O código OTOH que funciona com um banco de dados provavelmente está ligado à E / S e os identificadores em caixa não terão nenhum gargalo.

Em um mundo perfeito, os identificadores seriam imutáveis ​​e apenas comparáveis ​​em termos de igualdade; bytes reais seriam um detalhe de implementação. Identificadores não relacionados teriam tipos incompatíveis, portanto você não pode usar um por outro por engano. Sua solução praticamente se encaixa na conta.

Você não pode fazer isso, as enumerações devem ser predefinidas. Portanto, a menos que você esteja disposto a pré-definir todo o espectro de possíveis valores de IDs de clientes, seu tipo será inútil.

Se você transmitir, desafiaria seu objetivo principal de impedir atribuir acidentalmente um ID do tipo A a um ID do tipo B. Portanto, as enums não são úteis para o seu propósito.

Isso levanta a questão, porém, se seria útil criar seus tipos para identificação do cliente, identificação do pedido e identificação do produto descendo do Int32 (ou Guid). Eu posso pensar em algumas razões pelas quais isso estaria errado.

O objetivo de um ID é identificação. Tipos integrais já são perfeitos para isso, eles não são mais identificados descendo deles. Não há especialização necessária nem desejada, seu mundo não será representado melhor por ter tipos diferentes para identificadores. Então, do ponto de vista de OO, seria ruim.

Com sua sugestão, você deseja mais do que segurança de tipo, deseja segurança de valor e isso está além do domínio de modelagem, que é um problema operacional.