整数識別子を列挙型にマッピングすることの欠点は何ですか？

私はこのような識別子のカスタム型を作成することを考えています：

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

これの主な動機は、orderItemIdを予期していた関数に誤ってorderItemIdを渡すようなバグを防ぐことです。

列挙型は、典型的な.NET Webアプリケーションで使用するすべてのものとシームレスに動作するようです。

• MVCルーティングは正常に動作します
• JSONシリアル化は正常に動作します
• 私がうまくいくと思うすべてのORM

だから今、私は「なぜ私はこれをするべきではないのだろうか？これらは私が考えることができる唯一の欠点です。

• 他の開発者を混乱させる可能性があります
• 非整数の識別子がある場合、システムに不整合が生じます。
• のように、追加のキャストが必要になる場合があり(CustomerId)42ます。しかし、ORMおよびMVCルーティングは通常、enum型の値を直接渡すので、これが問題になるとは思いません。

だから私の質問は、何が欠けているのですか？これはおそらく悪い考えですが、なぜですか？

主にあなたが述べた理由のために、あらゆる種類の識別子に対してタイプを作成することは素晴らしい考えです。適切な構造体またはクラスにすることでより多くのオプションが提供されるため、列挙型として実装することでそれを行いません：

• 暗黙的な変換をintに追加できます。考えてみると、それはint-> CustomerIdという別の方向です。これは、消費者からの明示的な確認に値する問題のある方向です。
• 許可される識別子と許可されない識別子を指定するビジネスルールを追加できます。intが正であるかどうかの弱いチェックだけではありません。場合によっては、可能なすべてのIDのリストがデータベースに保持されますが、展開中にのみ変更されます。次に、適切なクエリのキャッシュされた結果に対して特定のIDが存在することを簡単に確認できます。これにより、無効なデータが存在する場合にアプリケーションが迅速に失敗することを保証できます。
• 識別子のメソッドは、高価なDB存在チェックの実行や、対応するエンティティ/ドメインオブジェクトの取得に役立ちます。

これの実装については、記事Functional C＃：Primitive obsessionで読むことができます。

それは賢いハックですが、それでもハックは意図されていない目的のために機能を悪用します。ハックには保守性にコストがかかるため、他の欠点を見つけることができないだけでなく、同じ問題を解決するためのより慣用的な方法と比較して大きな利点が必要です。

慣用的な方法は、単一のフィールドでラッパー型または構造体を作成することです。これにより、より明確で慣用的な方法で同じタイプセーフティが得られます。あなたの提案は確かに賢いですが、ラッパー型を使用することには大きな利点はありません。

私のPOVから、アイデアは良いです。関係のないクラスの識別子に異なる型を与え、そうでなければ型を介してセマンティクスを表現し、コンパイラにそれをチェックさせたいという意図は良いものです。

.NETのパフォーマンス面でどのように機能するかわかりません。たとえば、列挙値は必ずしもボックス化されています。とにかくデータベースで動作するOTOHコードはおそらくI / Oにバインドされ、ボックス化された識別子はボトルネックにはなりません。

完璧な世界では、識別子は不変であり、平等に関してのみ匹敵します。実際のバイトは実装の詳細になります。関連のない識別子には互換性のない型があるため、誤って別の識別​​子を使用することはできません。あなたのソリューションは実質的に法案に適合します。

これを行うことはできません。列挙型は事前に定義する必要があります。そのため、顧客IDの可能な値の全範囲を事前に定義しない限り、タイプは役に立たなくなります。

キャストすると、タイプAのIDをタイプBのIDに誤って割り当てることを防ぐという主な目的に反することになります。したがって、列挙型は目的に役立ちません。

ただし、Int32（またはGuid）から派生して、顧客ID、注文ID、および製品IDのタイプを作成すると役立つ場合は、質問が表示されます。これが間違っている理由を考えることができます。

IDの目的は識別です。積分型はすでにこれに最適であり、それらから派生することで識別型を取得することはありません。特殊化は必要ありませんし、望ましいこともありません。識別子に異なるタイプを持たせることで、あなたの世界がより良く表現されることはありません。したがって、オブジェクト指向の観点からは、それは悪いでしょう。

あなたの提案では、型の安全性以上のものが必要であり、価値の安全性が必要であり、それはモデリング領域を超えており、それは運用上の問題です。