[Разработка веб-сайтов, PHP, Проектирование и рефакторинг] Сущности (entities) и сервисы (services) как основа распределенной логики для MVC шаблона проектирования
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
При разработке разных по масштабу приложений становится все более интересно применять различные подходы к проектированию веб приложения. В последнее время особо остро встал вопрос о разделении логики в большом проекте, базирующийся на MVC шаблоне проектирования.
Сущности и сервисы
Сущности
Поскольку задачи стали более сложные и комплексные, а данные в БД хранить все невозможно, то было принято решение о создание сущностей статичных данных в проекте. Суть простая — в определенном месте хранятся базовые статичные данные, которыми можно оперировать в PHP коде, а в БД заносятся их англоязычное представление.
В базовом представлении класс Entity.php может иметь следующий вид:
declare(strict_types = 1);
namespace entities;
class Entity {
protected static $map;
public static function getMap():array {
return static::$map;
}
}
Наследники его должны реализовать свойство $map, которое будут получать следующим образом:
E1::getMap();
Причем, большинство статичных данных будут удовлетворять логике получения. Если требуется группировать данные или выделить дополнительные, то это логика реализуется уже в классах наследниках.
Сервисы
Сервисы предназначены для хранения бизнес логики приложения. Помимо этого, сервисы можно использовать как логика отдельная от фреймворка. Сервис — это набор методов, который реализует логику приложения. Условия, которые были определены сервису:
- сервис не должен самостоятельно обращаться к контроллерам и представлениям;
- сервис может обращаться к базе данных, моделям и сущностям.
В лучшем случае, контроллер должен передавать сервису все необходимые данные, но может возникнуть такая ситуация, что ему потребуется самостоятельно обратиться к какой-то модели, чтобы получить данные. Ничего страшного в этом нет, но лучше придерживаться логики, что маршрутами данных оперирует контроллер.
По умолчанию сервис не реализует никакую стандартную логику, поскольку является уникальным исполнением части проекта. Поэтому, было принято решение, что базовый класс сервиса не будет создан. Хотя, стоит отметить, что базовые классы лучше создавать, даже если они будут пустыми. Это объясняется тем, что может наступить такой момент, что всем наследникам надо будет иметь одинаковую логику или выполнять какой-то метод. Чтобы не производить во всех классах изменения в области наследования, проще изначально сделать наследование от базового класса, в котором реализовать данную ситуацию куда менее сложнее и дешевле в области временных ресурсов.
В общем представлении поток данных в предлагаемой архитектуре можно представить следующим образом:
- Данные или запрос поступает в контроллер.
- Контроллер общается с моделью, сервисом и сущностью в двунаправленном порядке. Тут он получает и отдает какие-то данные.
- Сервис отдает данные в контроллер, получает или отдает данные в модель.
- Контроллер отдает полученные данные в представление.
Таким образом, получается, что данные и принцип работы приложения распределен между базовыми элементами MVC и новыми.
Заключение
Стоит отметить, что внедрение такого подхода позволило значительно упростить разработку приложений и контролировать поток данных. Большинство данных были вынесены из базы данных, что позволило сократить ее объем и увеличить общую скорость приложения за счет уменьшения количества запросов.
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка веб-сайтов, JavaScript, Node.JS] Архитектура современных корпоративных Node.js-приложений
- [Разработка веб-сайтов, JavaScript, Программирование] Политика общего происхождения и CORS: визуальное руководство (перевод)
- [Разработка веб-сайтов, PHP, Программирование, Go] Мне кажется, дело не в языке, а в том, как на нем пишут
- [PHP, Symfony, ReactJS] SSR: рендеринг ReactJS приложения на бекэнде используя PHP
- [Разработка веб-сайтов, PHP, Программирование, Будущее здесь] Как будет выглядеть программирование в 2025 году? (перевод)
- [.NET, ASP, Microsoft SQL Server, API, C#] ASP.NET Core MVC: WebAPI + Entity Framework + Microsoft SQL Server + Angular
- [Python, Проектирование и рефакторинг] Мониторинг демон на Asyncio + Dependency Injector — руководство по применению dependency injection
- [Программирование, Разработка мобильных приложений, Проектирование и рефакторинг, Управление разработкой] Какие навыки можно прокачать на проекте c большой кодовой базой
- Началось бета-тестирование PHP 8
- [Разработка веб-сайтов, Клиентская оптимизация] Вырезаем SSR и ускоряем Хабр в 10 раз
Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_php, #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_php, #_proektirovanie_proektov (проектирование проектов), #_mvc, #_veb_razrabotka (веб разработка), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_php, #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:41
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
При разработке разных по масштабу приложений становится все более интересно применять различные подходы к проектированию веб приложения. В последнее время особо остро встал вопрос о разделении логики в большом проекте, базирующийся на MVC шаблоне проектирования. Сущности и сервисы Сущности Поскольку задачи стали более сложные и комплексные, а данные в БД хранить все невозможно, то было принято решение о создание сущностей статичных данных в проекте. Суть простая — в определенном месте хранятся базовые статичные данные, которыми можно оперировать в PHP коде, а в БД заносятся их англоязычное представление. В базовом представлении класс Entity.php может иметь следующий вид: declare(strict_types = 1);
namespace entities; class Entity { protected static $map; public static function getMap():array { return static::$map; } } Наследники его должны реализовать свойство $map, которое будут получать следующим образом: E1::getMap();
Причем, большинство статичных данных будут удовлетворять логике получения. Если требуется группировать данные или выделить дополнительные, то это логика реализуется уже в классах наследниках. Сервисы Сервисы предназначены для хранения бизнес логики приложения. Помимо этого, сервисы можно использовать как логика отдельная от фреймворка. Сервис — это набор методов, который реализует логику приложения. Условия, которые были определены сервису:
В лучшем случае, контроллер должен передавать сервису все необходимые данные, но может возникнуть такая ситуация, что ему потребуется самостоятельно обратиться к какой-то модели, чтобы получить данные. Ничего страшного в этом нет, но лучше придерживаться логики, что маршрутами данных оперирует контроллер. По умолчанию сервис не реализует никакую стандартную логику, поскольку является уникальным исполнением части проекта. Поэтому, было принято решение, что базовый класс сервиса не будет создан. Хотя, стоит отметить, что базовые классы лучше создавать, даже если они будут пустыми. Это объясняется тем, что может наступить такой момент, что всем наследникам надо будет иметь одинаковую логику или выполнять какой-то метод. Чтобы не производить во всех классах изменения в области наследования, проще изначально сделать наследование от базового класса, в котором реализовать данную ситуацию куда менее сложнее и дешевле в области временных ресурсов. В общем представлении поток данных в предлагаемой архитектуре можно представить следующим образом: 
Таким образом, получается, что данные и принцип работы приложения распределен между базовыми элементами MVC и новыми. Заключение Стоит отметить, что внедрение такого подхода позволило значительно упростить разработку приложений и контролировать поток данных. Большинство данных были вынесены из базы данных, что позволило сократить ее объем и увеличить общую скорость приложения за счет уменьшения количества запросов. =========== Источник: habr.com =========== Похожие новости:
Разработка веб-сайтов ), #_php, #_proektirovanie_i_refaktoring ( Проектирование и рефакторинг ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:41
Часовой пояс: UTC + 5