непостоянные свойства в модели данных предметной области - PullRequest
Новая
       32

непостоянные свойства в модели данных предметной области

0 голосов
/ 09 ноября 2018

Я слышал, что для небольшого проекта DTO не рекомендуется, например, здесь и здесь . Интересно, нормально ли для небольшого проекта (для команды) объединить непостоянные свойства в моделях предметной области? например: 

namespace Domain.Entities
{
    public class Candidate : BaseEntity
    {
        public Candidate()
        {
            // some construction codes
        }

        // region persistent properties

        public string FirstName { get; set; }
        public string LastName { get; set; }
        public bool? IsMale { get; set; }
        public DateTime BirthDate { get; set; }
        // other properties ...


        // region non-persistent properties
        public string FullName => $"{FirstName} {LastName}";
    }
}

Это просто, или я теряю что-то ценное таким образом?

1 Ответ

0 голосов
/ 09 ноября 2018

Я не сторонник определенного подхода, просто делюсь информацией ...

Я бы не стал помещать ваши вычисления FullName в DTO. DTO - это просто простой объект, действительно больше структуры, и в нем не должно быть никакой логики. Целью DTO является перемещение данных с одного уровня / уровня на другой и создание уровня косвенности, который позволяет модели вашего домена развиваться независимо от ваших клиентов. FullName в вашей сущности как непостоянное свойство имеет больше смысла, чем в DTO. Если вы хотите перейти на полное предприятие, оно будет в трансформаторе / адаптере.

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

Еще одним преимуществом DTO является хранение некоторых данных там, где они должны оставаться. Например, если у вас есть конфиденциальные данные в вашем объекте сущности, и вы не помещаете что-то на место, чтобы предотвратить их возвращение в веб-запросе, вы просто вытекли некоторую информацию со своего уровня сервера приложений (представьте себе поле пароля вашего пользователя юридическое лицо). DTO требует, чтобы вы думали о том, что отправляется клиенту и от него, и делает включение данных явно преднамеренным действием против непреднамеренного действия. DTO также упрощают документирование того, что действительно требуется для клиентского запроса.

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

Все сводится к решению, как вы хотите справиться с потенциальной утечкой данных, как вы хотите управлять своими клиентами (если можете) и насколько сложной может стать ваша модель.

...