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





Сервис - это широкая категория, охватывающая любую ценность, функцию или функцию, которая нужна приложению. Сервис обычно представляет собой класс с узкой, четко определенной целью. Он должен делать что-то конкретное и делать это хорошо.
Angular отличает компоненты от сервисов, чтобы повысить модульность и возможность многократного использования. Отделив функциональность компонента, связанную с представлением, от других видов обработки, вы можете сделать свои классы компонентов компактными и эффективными.
В идеале задача компонента - обеспечить взаимодействие с пользователем и не более того. Компонент должен представлять свойства и методы для привязки данных, чтобы быть посредником между представлением (отображаемым шаблоном) и логикой приложения (которое часто включает некоторое понятие модели).
Компонент может делегировать определенные задачи службам, например получение данных с сервера, проверку ввода данных пользователем или ведение журнала непосредственно на консоли. Определяя такие задачи обработки во внедряемом классе обслуживания, вы делаете эти задачи доступными для любого компонента. Вы также можете сделать свое приложение более адаптируемым, внедрив разных поставщиков одного и того же вида услуг в зависимости от обстоятельств.
Angular не поддерживает эти принципы. Angular действительно помогает вам следовать этим принципам, упрощая разделение логики вашего приложения на службы и делая эти службы доступными для компонентов посредством внедрения зависимостей.
Да, я попробовал по-своему, и мне очень нравится, как это работает сейчас. Я собираюсь и дальше двигаться в этом направлении. Спасибо.
Да, я думаю, вам что-то не хватает.
Общепринятая цель проектирования - «слабая связь». Возможность подкачки в другой реализации является основной причиной использования инъекции.
Даже если вы никогда не собираетесь использовать другую реализацию службы, предоставление ее посредством инъекции значительно упрощает тестирование. Если вы используете инъекцию, вы можете легко внедрить фиктивный сервис из теста, так что вы действительно модульное тестирование только компонента.
Итог: создание пользовательских классов из компонента или службы Angular - это просто использование Typescript в точности так, как это было задумано.
Однако вам нужно будет вручную внедрить какие-либо службы в каждый дочерний объект, который вы создаете, или передать в экземпляр родительского класса.
В большинстве случаев это не будет проблемой с точки зрения производительности, поскольку вы будете создавать экземпляры дочерних объектов только в тех случаях, когда вы уже создали экземпляр родительского объекта.
Думаю, я не был достаточно конкретным. Я создал объекты в одном из моих компонентов. Этим объектам необходим доступ к сервису, который внедряется в компонент. Похоже, что я могу передать ссылку на службу дочерним объектам в качестве параметра, и это даст им доступ к данным, хранящимся в службе. Не похоже, что это вызовет какие-либо проблемы, поскольку эти объекты создаются только компонентом, поэтому, хотя я вручную передаю службу, это происходит только тогда, когда создается экземпляр компонента и внедряется служба.