Константы базы данных в классе
Если у меня есть, скажем, таблица фильмов, которая, среди прочего, имеет поле int FilmTypeId и таблицу типов фильмов с идентификатором и значимым описанием в строках:
- 1 - ужас
- 2 - комедия
- ...
Как лучше всего использовать эту информацию в классе C#?
в настоящее время я бы использовал их как константы во вспомогательном классе (неуместно воздушный код):
public class FilmHelper
{
public const int HorrorFilmType = 1;
public const int ComedyFilmType = 2;
...
}
но это не кажется таким ремонтопригодным. Но я бы хотел избежать вызова базы данных каждый раз, когда я приходил использовать константу или дополнительный вызов db каждый раз, когда я использовал либо помощник, либо основную сущность.
Ответы 6
Список типов фиксированный или меняется?
Если исправлено, я бы инкапсулировал его в перечисление:
public enum FilmType {
Horror = 1,
Comedy = 2
}
Тогда просто забросьте. Вы можете использовать атрибуты (и несколько строк индивидуального кода) для хранения дополнительного описания для каждого элемента перечисления.
Если список изменится, я бы, вероятно, прочитал его один раз на ранней стадии приложения и кэшировал список в поиске где-нибудь (возможно, статический, возможно, в определенном кеше). Затем просто выполните поиск из кэшированной копии.
Вы можете пойти дальше, добавив свойства, которые изменяются между двумя представлениями.
Я всегда храню поиски кода в файлах перечисления, подобных этому
public enum ReportStatus
{
[Description("Reports that are running")] Running,
[Description("Reports that are pending to run")] Pending,
[Description("Reports that have errored while running")] Error,
[Description("Report completed successfully.")] Finished
}
Для чтения из тегов Description в перечислении я использую класс, аналогичный этому примеру, из Монстры получили мой .NET. Это дает вам гибкость для одновременного сохранения идентификатора, кода и описания объекта типа поиска в перечислении.
Как бы я ни ненавидел поиск кода, у меня всегда есть мои перечисления, которые отражают их, поэтому вам никогда не нужно обращаться к базе данных, чтобы выяснить их, и у вас есть строгая типизация для них в вашем коде. Требуется небольшая гибкость для изменения взглядов во время выполнения, но я считаю, что это приемлемый компромисс.
Я бы фактически вытащил его из базы данных при запуске приложения или присоединился к таблице в любых запросах, где используются данные.
Основная причина наличия его на стороне класса также заключается в том, что dal будет структурой сущностей, поэтому я мог бы делать такие вещи, как: Film film = (из f в context.Film, где film.FilmId = HorrorFilmType select f) .FirstOrDefault ();
И вы не могли сделать это с помощью поиска, заполненного из базы данных?
Конечно: о) Я просто немного подробнее объяснил свою ситуацию
Вы можете использовать строгий тип без строгой типизации значений.
class FilmType : Dictionary<int, string> {}
Затем просто загрузите значения во время загрузки приложения, как предложил Джоэл.
Если вас больше беспокоят фактические значения во время компиляции, тогда вы не добьетесь большего успеха, чем перечисление.
Я думаю, что они оба лучше, чем то, что у меня есть, я просто решаю, по какому пути идти. Спасибо!
Что касается использования перечислений ... в зависимости от того, что представляет собой значение перечисления (например, столбец IDENTITY), я мог бы добавить столбец StaticIdentifier в свою таблицу и сделать поле THAT значением перечисления для поиска (соответствующим образом изменив мои сохраненные процедуры, чтобы поле статического идентификатора вместо столбца идентификатора). Столбцы идентификаторов неизбежно путаются между DEV, QA и PROD, и мне не нужны эти хлопоты.
В моем ответе предполагается, что вы хотите явно кодировать эти значения в своей базе данных.
Раньше я создавал скрипт, который создает мои файлы констант. (У меня также был сценарий SQL, который выводил код C# при запуске с текстовым выводом, поэтому я мог просто вставить его в файл и сразу же использовать эту константу.)
Если вы сделаете это, вы можете сделать его частью вашей сборки непрерывной интеграции и просто получить последнюю версию этого файла, когда сборка будет завершена.
Здесь следует помнить, что когда вы удаляете строки из этой таблицы, некоторый код может стать недоступным / мертвым, и, в зависимости от того, как вы реализуете свой скрипт, сборки будут ломаться (это хорошая вещь, чтобы заставить вас удалить мертвые код).
кажется, что для чего-то, что должно быть довольно простым, требуется много сложностей.
Мне нравится идея перечисления, но мне также нравится иметь таблицу со значением идентификатора на сервере базы данных, поэтому для кого-то, смотрящего только на sql, будет понятно значение идентификаторов.