Каковы недостатки в отображении интегральных идентификаторов в перечисления?

Я думал о создании пользовательских типов для идентификаторов, как это:

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

Моя основная мотивация для этого состоит в том, чтобы предотвратить ошибку, при которой вы случайно передаете orderItemId функции, ожидающей orderItemDetailId.

Кажется, перечисления работают без проблем со всем, что я хотел бы использовать в типичном веб-приложении .NET:

• MVC роутинг работает нормально
• JSON-сериализация работает отлично
• Каждый ORM, о котором я могу думать, прекрасно работает

Так что теперь я задаюсь вопросом: «Почему я не должен это делать?» Это единственные недостатки, о которых я могу думать:

• Это может смутить других разработчиков
• Это вносит несоответствие в вашу систему, если у вас есть неинтегральные идентификаторы.
• Это может потребовать дополнительного литья, вроде (CustomerId)42. Но я не думаю, что это будет проблемой, поскольку маршрутизация ORM и MVC обычно передает вам значения типа enum напрямую.

Итак, мой вопрос: чего мне не хватает? Вероятно, это плохая идея, но почему?

Отличная идея - создать тип для каждого типа идентификатора, в основном по указанным вами причинам. Я бы не стал делать это, реализуя тип как enum, потому что создание правильной структуры или класса дает вам больше возможностей:

• Вы можете добавить неявное преобразование в int. Когда вы думаете об этом, это другое направление, int -> CustomerId, которое является проблематичным и заслуживает явного подтверждения со стороны потребителя.
• Вы можете добавить бизнес-правила, которые определяют, какие идентификаторы являются приемлемыми, а какие - нет. Это не просто слабая проверка, является ли int положительным: иногда список всех возможных идентификаторов сохраняется в базе данных, но изменяется только во время развертывания. Затем вы можете легко проверить, что данный идентификатор существует по кешированному результату правильного запроса. Таким образом, вы можете гарантировать, что ваше приложение быстро выйдет из строя при наличии неверных данных.
• Методы идентификатора могут помочь вам выполнить дорогостоящие проверки существования БД или получить соответствующий объект сущности / домена.

Вы можете прочитать о реализации этого в статье Функциональный C #: Примитивная одержимость .

Это умный взлом, но все же взлом в том, что он использует функцию для чего-то, что не является его целью. Хаки имеют затраты на ремонтопригодность, поэтому недостаточно, чтобы вы не могли найти никаких других недостатков, также необходимо иметь значительные преимущества по сравнению с более идиоматическим способом решения той же проблемы.

Идиоматическим способом было бы создать тип или структуру оболочки с одним полем. Это обеспечит вам такую ​​же безопасность типов более явным и идиоматическим способом. Хотя ваше предложение по общему признанию умно, я не вижу каких-либо существенных преимуществ в использовании типов обертки.

Из моего POV идея хорошая. Хорошее намерение дать разные типы несвязанным классам идентификаторов и иным образом выразить семантику через типы и позволить компилятору проверить это.

Я не знаю, как это работает в .NET с точки зрения производительности, например, значения перечисления обязательно помещены в квадрат. Код OTOH, который работает с базой данных, скорее всего, связан с вводом / выводом, и идентификаторы в штучной упаковке не будут узким местом.

В идеальном мире идентификаторы были бы неизменными и сопоставимыми только по равенству; фактические байты будут деталями реализации. Несвязанные идентификаторы будут иметь несовместимые типы, поэтому вы не можете использовать один для другого по ошибке. Ваше решение практически отвечает всем требованиям.

Вы не можете сделать это, перечисления должны быть предопределены. Поэтому, если вы не готовы заранее определить весь спектр возможных значений идентификаторов клиентов, ваш тип будет бесполезен.

Если вы разыгрываете, вы бы бросили вызов своей основной цели - предотвратить случайное присвоение идентификатора типа A идентификатору типа B. Таким образом, перечисления не помогают вашей цели.

Это поднимает вопрос, хотя, если было бы полезно создать ваши типы для идентификатора клиента, идентификатора заказа и идентификатора продукта, убираясь от Int32 (или Guid). Я могу думать о причинах, почему это было бы неправильно.

Целью идентификатора является идентификация. Интегральные типы уже идеально подходят для этого, они не получают больше идентификации, спускаясь с них. Специализация не требуется и не нужна, ваш мир не будет лучше представлен различными типами идентификаторов. Так что с точки зрения ОО это было бы плохо.

С вашим предложением вы хотите больше, чем безопасность типов, вы хотите ценить безопасность, и это выходит за рамки области моделирования, что является эксплуатационной проблемой.