Слои приложения в Symfony? Здравствуйте
Как показывает практика, если писать на Symfony опираясь на документацию, фреймворк "подталкивает" пользователя к использованию слоев приложения со своей зоной ответственности. К примеру, общение с бд идет через репозиторий, бизнес-логику чаще всего описывают в модели, дробля на сервисы. Хоть и следовать документации - хорошее дело, пользователи, руководствуясь собственным опытом или той/иной методологией, вольны создавать собственные слои.
У меня возникла необходимость создать следующее:
- Слой, отвечающий за атомарные операции с бд (прим. - save(), delete(), может какой-то цикл с небольшой логикой)
- Разделение команды на инициализацию, и её выполнение. Были идеи для выделения выполнения в отдельный сервис, но что в таком случае делать с output'ом? (Примерно так же как и handler в Messenger компоненте)
Сталкивались ли вы с такими слоями?
Буду признателен за подробный ответ
Слои приложения в Symfony? Здравствуйте
Как показывает практика, если писать на Symfony опираясь на документацию, фреймворк "подталкивает" пользователя к использованию слоев приложения со своей зоной ответственности. К примеру, общение с бд идет через репозиторий, бизнес-логику чаще всего описывают в модели, дробля на сервисы. Хоть и следовать документации - хорошее дело, пользователи, руководствуясь собственным опытом или той/иной методологией, вольны создавать собственные слои.
У меня возникла необходимость создать следующее:
- Слой, отвечающий за атомарные операции с бд (прим. - save(), delete(), может какой-то цикл с небольшой логикой)
- Разделение команды на инициализацию, и её выполнение. Были идеи для выделения выполнения в отдельный сервис, но что в таком случае делать с output'ом? (Примерно так же как и handler в Messenger компоненте)
Сталкивались ли вы с такими слоями?
Буду признателен за подробный ответ
Как показывает практика, если писать на Symfony опираясь на документацию, фреймворк "подталкивает" пользователя к использованию слоев приложения со своей зоной ответственности. К примеру, общение с бд идет через репозиторий, бизнес-логику чаще всего описывают в модели, дробля на сервисы. Хоть и следовать документации - хорошее дело, пользователи, руководствуясь собственным опытом или той/иной методологией, вольны создавать собственные слои.
У меня возникла необходимость создать следующее:
- Слой, отвечающий за атомарные операции с бд (прим. - save(), delete(), может какой-то цикл с небольшой логикой)
- Разделение команды на инициализацию, и её выполнение. Были идеи для выделения выполнения в отдельный сервис, но что в таком случае делать с output'ом? (Примерно так же как и handler в Messenger компоненте)
Сталкивались ли вы с такими слоями?
Буду признателен за подробный ответ
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Да, я сталкивался с подобными слоями в Symfony. Действительно, фреймворк предполагает использование слоев приложения для более удобной и структурированной разработки.
Что касается слоя, отвечающего за атомарные операции с базой данных, то его можно легко реализовать через использование репозиториев или сервисов для взаимодействия с базой данных. В вашем случае, вы можете создать отдельный класс, который будет содержать методы для выполнения самых базовых операций с базой данных, таких как сохранение данных (save()), удаление данных (delete()) и прочее.
Что касается разделения команды на инициализацию и выполнение, то здесь также можно использовать подход с созданием отдельных сервисов. Вы можете создать сервис, который будет отвечать за инициализацию команды и возвращать объект, который затем будет передан другому сервису для выполнения этой команды. В случае необходимости работы с output'ом, вы можете передавать соответствующий объект или использовать события для обработки вывода информации.
В целом, в Symphony есть множество способов организации слоев приложения, и вам следует выбрать тот подход, который наиболее удобен и эффективен для вашего проекта. Надеюсь, мой ответ был полезен для вас. Если у вас есть другие вопросы, не стесняйтесь задавать.