Как стать автором
Обновить

Комментарии 13

Поскольку задачи стали более сложные и комплексные, а данные в БД хранить все невозможно

CQRS смотрели? Он как раз это лечит, причем масштабирумо.

Про сущности со статикой: как в map данные будут из базы попадать? Как будет обеспечена актуальность? Это in-memory cache?

Про сервисы: по-моему вы переизобрели сервисный слой, разве нет? в sf что то подобное было принято делать еще со второй версии.
CQRS не смотрел, ознакомлюсь.

Как в map данные будут из базы попадать?

Суть Entity в хранении статичных данных, которые разработчик вбивает сам в проекте. То есть, вы сами формируете массив данных.

Как будет обеспечена актуальность?

Тут уже придется написать собственный метод актуализации, так как автоматически обновлять это не получится.
Что-то если честно какая-то недосказанность наблюдается в данной статье, как будто это черновик. Вся статья просто проходит на вступление о правильном проектировании системы…
Возможно вы правы, но это единственное, что я хотел донести. Узнал, попробовал, понравилось, рассказал. Далее буду развивать темы более обширно.
Вы узнали что-то новое для себя, причем ггубоко не копали. Но далеко не факт что новым оно будет и для остального мира. Не надо сразу бежать рассказывать об этом на хабре. Хотя понимаю, сам таким был)
Согласен, но в комментариях можно много нового и дельного узнать)
В общем представлении поток данных в предлагаемой архитектуре можно представить следующим образом:

Совсем непонятно. И противоречит тексту, например, "сервис не должен самостоятельно обращаться к контроллерам и представлениям", а стрелка между сервисами и контроллерами двунаправленная. Как-то то ли с терминологией проблема, то ли потоки данных не разделены на параметры и результаты вызовов, то ли ещё что.


Примеры более-менее реального кода помогли бы разобраться, возможно, но их нет. Без них непонятно чем Entity отличается от Model

Да, в схеме не очень корректно отобразил. Сервис отдает данные, но не обращается к контроллеру с просьбой что-то сделать. Надо было разделить стрелки на запросы и ответы.

Без них непонятно чем Entity отличается от Model


В моем представлении Model отражает таблицу базы данных и оперирует запросами к ней. В случае таблиц справочников, где данные не могут изменяться пользователями системы, в моем представлении, нет смысла создавать такую таблицу. Следовательно, модель не нужна, а сущность реализует статичное хранение данных на стороне сервера приложения.

Явно с терминологией что-то не общепринятое. Сущность, обычно, как раз что-то активно изменяющееся при работе системы. Даже обычными пользователями, не админами сайта.

Оттого что модель получает данные не из базы, она не перестает быть моделью.
Посмотрите мой ответ выше, я выразил свое виденье модели и сущности. Если не расценивать модель как отражение таблицы базы данных, то вы правы.

Базовые классы — весьма сомнительный подход. По возможности лучше использовать композицию вместо наследования, да это более трудозатратно за счёт инжекта зависимости, зато более универсально и поддерживаемо, и не подвержено side эффектам.
Если нужен какой-то общий признак на уровне классов, то используйте пустой интерфейс.

Можете привести сравнительный пример на базе концептуального примера?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.