Правильный способ управления данными модели в Angular 10

Допустим, я хочу создать простую игру в крестики-нолики, и у меня есть модель игрового поля. И мой вопрос, где я должен разместить логику для управления этой платой. Например.

export class Board{
  boardString: string;
  rows: string[];
  separator: string;

  constructor(boardString: string, separator: string = '|'){
    this.boardString = boardString;
    this.separator = separator;
    this.rows = this.boardString.split('|');
  }
}
// inside model class 
atIndex(index: number): string{
    const atCol = index % this.rows.length;
    const atRow = (index - atCol) / this.rows.length;
    return this.rows[atRow][atCol];
  }

isFinished(): boolean {
  // check if game is finished
}

getRow(index): string{
 return this.rows[index]
}

vs

// or in the Service
atIndex(index: number): string{
    const atCol = index % this.boardModel.rows.length;
    const atRow = (index - atCol) / this.boardModel.rows.length;
    return this.boardModel.rows[atRow][atCol];
  }

isFinished(): boolean{
  // check if game is finished
}

getBoardRow(index): string{
  return this.boardModel.rows[index];
}

Не знаю, ясно ли я выразился. Крестики-нолики это просто пример. Я хочу знать, где я должен разместить логику, отвечающую за управление свойствами модели? Я читал в документации, что вся логика должна быть внутри сервисов. Но для меня в некоторых случаях это больше подходит к классу модели (например, геттеры). Это анти-шаблон для хранения методов внутри класса модели?

  • внутри модельного класса (Board)
  • внутренняя служба, использующая эту модель (GameService)
  • объединить два вышеперечисленных
  • создать сервисы специально для этой модели (BoardService) со всеми необходимыми функциями и внедрить их в другой сервис (GameService)

person Tasteless    schedule 21.09.2020    source источник


Ответы (1)


Высказывание I read from documentation that all logic should be inside services немного вводит в заблуждение. Конечно, это действительно зависит от того, что делает логика, и абсолютно неверно, что вся логика должна быть в службах.

Для моделей было бы разумно сохранить некоторую логику внутри. Отличным примером может служить какой-нибудь класс Modal или Notification, который после инициализации будет предоставлять некоторую функциональность, например close, onClose и т. д. Представьте, что вам нужно закрыть свое уведомление через такую ​​службу, как notificationService.close(<notificationUniqueId).

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

Хотя я понимаю твою борьбу. Иногда может случиться так, что логика вашего пользовательского интерфейса будет распространяться на несколько компонентов. Тем не менее, я бы все равно воздержался от помещения его в Service. Лично я стараюсь ограничивать услуги логикой, которая a) performs some API calls, b) formats data in some way или c) manages state and actions throughout the application. В моих недавних проектах мы реализовали еще один тип Injectable, который мы назвали CommonUIHandler — это подмножество классов обрабатывало повторяющуюся логику в компонентах. Но это создало еще один уровень абстракции и предотвратило рост традиционных сервисов, когда в них не было необходимости.

Я уверен, что если вы будете искать Angular design patterns, вы найдете много ценных ресурсов. В качестве примера стоит упомянуть https://coryrylan.com/blog/angular-design-patterns-feature-services

person Jiri Kralovec    schedule 22.09.2020