Статус Entities в .NET Core Entity Framework - предлагаемая реализация

Question

Я новичок в разработке программного обеспечения с полным стеком, и у меня есть задание создать простое веб-приложение с полным стеком в .NET Core, Entity Framework Core (когда речь идет о серверной части), в котором будет храниться какой-то сотрудник. данные. Теперь, допустим, у меня есть объект Employee. Нам также необходимо каким-то образом реализовать позицию сотрудника (сотрудник может иметь должность внутреннего разработчика, внешнего разработчика, менеджера проекта и т. Д.). Вот почему я также создал этот класс EmployeePosition, чтобы в Employee было свойство EmployeePosition. У меня также есть другие подобные статусные объекты, такие как EmployeePosition в приложении.

Затем EmployeePosition будет добавлен в отдельную таблицу в базе данных, и, таким образом, это может быть применимо к любой компании, которая "будет использовать" это приложение (просто используйте разные начальные данные). Я буду использовать устаревшую базу данных для заполнения.

Теперь кажется, что это будет работать, но это также кажется мне слишком грубым, потому что всякий раз, когда мне нужно будет выполнить операцию со статусом в хранилище,Я мог бы использовать магический номер идентификатора состояния или жестко задавать свойство имени состояния где-нибудь в методе (если у меня нет более разумного обходного пути для данной операции), например, «Switch (Position.Name) case»front-end ": делать вещи" и т. д.

Могу ли я получить предложение или указание о том, как лучше это реализовать, я на правильном пути?

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

public class Employee
    {
        [Key]
        public int Id { get; set; }
        [Required]
        public string FirstName { get; set; }
        [Required]
        public string LastName { get; set; }
        [Required]
        public string Image { get; set; }
        [Required]
        public string Email { get; set; }
        [Required]
        public string Phone { get; set; }
        [Required]
        public EmployeePosition Position { get; set; }      

public class EmployeePosition
    {
        [Key]
        public int Id { get; set; }
        [Required]
        public string Name { get; set; }
    }

Answer 1

То, что вы можете сделать, - это создать Enum для должностей сотрудников.

public enum EmployeePosition
{
   Backend = 0,
   Frontend = 1,
   DBA = 2,
}

И для вашего сотрудника

public class Employee
{
    [Key]
    public int Id { get; set; }
    [Required]
    public string FirstName { get; set; }
    [Required]
    public string LastName { get; set; }
    [Required]
    public string Image { get; set; }
    [Required]
    public string Email { get; set; }
    [Required]
    public string Phone { get; set; }
    [Required]
    public EmployeePosition Position { get; set; } 
}

Тогда вы можете использовать

If (Employee.Position == EmployeePosition.Backend)
{
     // your logic.
}

Answer 2

У вас, к сожалению, противоречивые требования. Вы говорите, что ваша программа «независима от статуса»:

EmployeePosition будет затем занесен в отдельную таблицу в базе данных, и, таким образом, он может быть применим к любой компании, которая «будет использовать» это приложение(просто используйте разные начальные данные).

И все же, это действительно не так:

Потому что всякий раз, когда мне нужно будет выполнить операцию со статусом в хранилище, ябудет использовать магический номер идентификатора состояния или жестко закодировать свойство Name состояния где-нибудь в методе (если у меня нет более разумного обходного пути для данной операции), например «Switch (Position.Name) case» front-конец ": делать вещи" и т. д.

Таким образом, одно из этих требований должно "победить". Либо ваш код знает, что такое разные статусы (и поэтому разные начальные данные не будут работать), либо не работает.

Если первое требование более важно:

Сохраняйте свой код таким, какой он есть, у вас есть вполне разумная модель для N числа статусов, для которых они не известны заранее, а также нет какой-либо логики, специфичной для данной записи

ЕслиВторое требование более важно:

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