Блог

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

 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]
}
  

против

 // 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];
}
  

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

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

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

Для моделей было бы разумно сохранить некоторую логику внутри. Отличным примером может быть Modal Notification класс some или, который будет предоставлять некоторую функциональность после инициализации, например 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 . В моих недавних проектах мы реализовали другой инъекционный тип, который мы назвали CommonUIHandler — это подмножество классов обрабатывало повторяющуюся логику во всех компонентах. Но это создало еще один уровень абстракции и препятствовало росту традиционных сервисов, когда это не требовалось.

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