Разница между ViewModel и Entity

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

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

Сущность — это объект, который будет представлять автономное состояние, может содержать данные и поведение, которые будут выполняться в соответствии с бизнес-требованиями вашего приложения.

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

Чего вам не хватает, так это DTO (объект передачи данных). Этот тип объекта мы используем при отправке запросов/получении ответов от API/внешних уровней.

Когда мы делаем вызов API на сервер, мы получаем ответ, который обычно содержит данные JSON. Затем мы должны обработать этот ответ, построить объект, сопоставить свойства и значения этого объекта (модель представления) и так далее. Для вызова и API мы обычно берем данные из Viewmodels, сопоставляем их с DTO и отправляем по сети.

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

Обновлено:

Предположим, у нас есть форма входа, в которой представлены входные данные для имени пользователя, пароля и флажок «Оставаться в системе». У нас также есть логический флаг, который сообщает нам, что форма действительна, т. Е. Истина, когда все поля формы заполнены действительными данными, в противном случае — ложь. Кнопка «Вход» будет включена или отключена в зависимости от этого значения, предотвращая ненужные попытки входа в систему. Наконец, нам нужно сохранить строковое сообщение, которое в конечном итоге покажет пользователю текст ошибки.

Таким образом, модель представления для этой формы входа может быть определена следующим образом:

class LoginFormViewModel {

  username: string | null;
  password: string | null;
  persistentCookie: boolean = false;
  isValid: boolean = true;
  message: string | null;

}

Обратите внимание на эту модель представления, содержащую данные, которые будут привязаны к логике пользовательского интерфейса/представления и визуальным компонентам.

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

class LoginRequestDto {

  username: string;
  password: string;
  persistCookie: boolean;

  constructor(username: string, password: string, pers: boolean) {
    this.username = username;
    this.password = password;
    this.persistCookie = pers;
  }

}

class LoginView {

  ctor(viewModel: LoginViewModel) {
    this.vm = viewModel;
  }

  onLoginClick() {
    this.doLogin();
  }

  async function doLogin() {
    var vm = this.vm;
    var requestDto = new LoginRequestDto(vm.username, vm.password, vm.persistentCookie);
  
    const result = await this.httpClient.Post('/login', requestDto);
    if (result.authenticated) {
      this.setState({
        isAuthenticated: true,
        //etc
      });
    }
  }
}

Модель представления привязана к необходимым данным для представления, DTO будут привязаны к выполняемому запросу в соответствии со спецификациями API/конечной точки,

Обновлено еще раз:

LoginView представляет собой некоторую форму входа, которая предоставляет визуальные компоненты, с которыми пользователь может взаимодействовать. Он содержит только код, который имеет дело с визуальной обратной связью. Для лучшей организации кода в представлении используется другой класс с именем LoginViewModel, который будет хранить состояние данных в контексте представления. Представление отражает данные из модели представления, а модель представления принимает входные данные из представления в двусторонней привязке данных. Затем мы можем создать еще один модуль в наших приложениях, например LoginService, который будет обрабатывать действия, которые нам нужно будет запускать из представления. Таким образом, поток данных: View, ViewModel, Service или Business Layer (LoginService), затем LoginRequestDto передается на уровень инфраструктуры, который отправит наш объект на цель. После этого мы можем получить ответ. Мы получаем эти данные, создаем LoginResponseDto и возвращаем их на наш сервисный/бизнес-уровень. Затем мы можем принимать решения, основанные на бизнес-логике, что делать дальше (успешный вход в систему или нет), перенаправлять на другое представление/страницу, представлять сообщение пользователю и т. д.