Частично это зависит от того, имеют ли идентификаторы для ваших статусов гарантированные значения или могут ли идентификаторы изменяться для каждой базы данных (через IDENTITY). Лично для статусов я предпочитаю фиксированный - который дает вам наибольшую гибкость и наименьшие накладные расходы - вы можете выбрать использование enum (или, возможно, несколько констант, если это более удобно), и вам никогда не придется добавлять косвенное обращение, то есть «получить идентификатор» то есть open ".
Однако это не всегда возможно, и когда не , все равно определенно полезно кешировать и использовать их повторно (чтобы избежать попадания в БД для этого поиска). Тем не менее, я бы избегал синглтона, не в последнюю очередь потому, что он не будет играть хорошо, если вам когда-нибудь понадобится поговорить с более чем одной базой данных - идентификаторы в каждой из них могут быть разными. Однако любая подходящая реализация кэша (или, возможно, IoC / DI) должна позволять вам хранить соответствующие данные (возможно, какой-то словарь). Синглтоны - это тоже немного боли обычно , если вам нравится тестирование и т. Д.
Но: перечисление и фиксированные значения идентификатора намного проще.
Обратите внимание, что при реализации любой изменение списка состояний является нетривиальной операцией, не в последнюю очередь это будет большой UPDATE (или несколько, если вы денормализованы).