Правильное ли использование принципов DDD, и чем заменить Repository?

galliard,

советую посмотреть на такую штуку, как интерфейсы, они вполне решают обозначенную тобой проблему

Вообще-то я про интерфейс для репозитория и написал в предыдущем сообщении. "Репозиториев, реализующих общий интерфейс, может быть несколько. Например, один для MySQL, второй - для PostgreSQL, третий - вообще для какого-то NoSQL-хранилища". Только вот интерфейс как раз-таки не решает то, что я описал.

Но если в контроллере только эти 2 метода и нужны, то зачем тащить туда весь сервис остальными 8ю ненужными?

Потому что репозиторий, как я уже сказал, это не сервис. Если ты считаешь иначе - твое право, переубеждать не буду. :)

1) Автокомплит.

Автокомплит легко добавляется с помощью phpdoc, который используются в php повсеместно

2) Сразу видно из каких компонентов состоит контроллер, что важно при рефакторинге, гораздо легче найти где какие компоненты используются.

Насчет этого согласен, но при наличии кучи аргументов в контроллере этот плюс становится не таким весомым.

Никогда не юзал в контроллере такие вещи, как "кеш" и "фабрика валидаторов", но допустим.

А где ты делаешь тогда валидацию и кеширование? Не в сервисном слое, надеюсь?

Правильное ли использование принципов DDD, и чем заменить Repository?

galliard, если говорить не конкретно о Doctrine, то слой репозиториев подразумевает то, что в них хранятся методы, делающие запросы к СУБД или к другим хранилищам. Репозиториев, реализующих общий интерфейс, может быть несколько. Например, один для MySQL, второй - для PostgreSQL, третий - вообще для какого-то NoSQL-хранилища. Понятное дело, что в один момент времени используют лишь одну реализацию репозитория (которую, как я понял, ты предлагаешь передавать в конструктор контроллера) в зависимости от того, где и как хранятся те или иные сущности.

Вот и скажи мне, если ты везде рассуешь обращение к КОНКРЕТНОЙ реализации репозитория, то удобно ли тебе будет переезжать, скажем, с MySQL на PostgreSQL? В одном случае поменяешь только лишь в сервисе обращение к другому репозиторию - и все. В другом - будешь лазать по коду, искать, где в контроллер передаются какие репозитории - и менять там на другую реализацию репозитория.

Аргументы типа "а может быть когда нибудь там придется добавить логики" я считаю не состоятельными

Ок, но я считаю иначе. Я не говорю про сервисы, все методы которых сплошь прокси, но если из 10 методов сервиса 2 будет проксями, то не вижу в этом особой проблемы.

то это повод пересмотреть архитектуру

В каждом контроллере нужен, как минимум, кеш, фабрика валидаторов, фабрика респонсов (чтобы ответы API были в едином формате) - это уже 3 параметра (сервиса) в конструктор. Ну, допустим, еще пара репозиториев, как ты предлагаешь, и пара сервисов. Итого уже 7 параметров на контроллер, и это я по-минимуму взял. Удобно? На мой взгляд, нет.

Правильное ли использование принципов DDD, и чем заменить Repository?

topuserman, разве? Просто делимся опытом же)

Правильное ли использование принципов DDD, и чем заменить Repository?

galliard,

репозитории не являются DAO

Что касается "И держать его в контейнере вместе с другими сервисами абсолютно нормально" - не соглашусь, но это, наверное, вкусовщина. Вы про доктрину и симфони толкуете? Ну, там - может быть. По крайней мере, по дефолту автовайринг в Симфони репозитории (вроде) в контейнер пихает, что позволяет сделать вывод, что они рассматриваются как сервисы.

Но если ее нет, то зачем создавать бессмысленный прокси-класс?

Но можно entity manager передать в конструктор контроллера и дергать напрямую прямо из экшена. Зачем бессмысленная прослойка в виде репозитория? Но, если серьезно, то я просто не сторонник смешивания слоев абстракции, а репозитории для меня не сервисы. Кроме того, я могу по пальцам пересчитать случаи, когда метод в сервисе просто прокси и все. Даже просто getById. В том или ином виде рано или поздно там появляется бизнес-логика так или иначе.

а вот тащить в контроллер весь контейнер - нет

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

Правильное ли использование принципов DDD, и чем заменить Repository?

galliard, на мой взгляд, контроллеры должны работать только с сервисным слоем. Если где-то из контроллеров дергать сервисы, а где-то напрямую DAO, то нарушается архитектура проекта.

К тому же на практике для отображения одной сущности можно не обойтись одним обращением к БД, либо же надо как-то обрабатывать данные, обращаясь к методам других сервисов.

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

Правильное ли использование принципов DDD, и чем заменить Repository?

galliard, да, но, судя по всему, не очень уловил Ваш ход мысли)

Правильное ли использование принципов DDD, и чем заменить Repository?

galliard, тогда бизнес-логика намертво завязывается на реляционные базы данных, а если не используется ORM, то вообще на конкретную СУБД. Слой репозиториев позволяет сделать при желании разные классы, реализующие единый интерфейс, но с разной реализацией методов работы с хранилищем.

Что из основ Wordpress нужно знать,чтобы можно было это вписать резюме?

Владимир Дружаев, вп держит хайлоад? Десятки тысяч запросов в секунду?

Как сделать юнит тест для метода отправки сообщений на Email?

Вопрос в чем?

Где и как хранить много ГБ изображений для сайта?

Иван Шумов, как раз поздно, потому что автор указал, что этот сайт не окупает даже стоимость аренды сервера. Значит, всякие AWS S3 в пролёте, потому что это не выгодно и загонит в еще больший минус. Тут надо думать не об оптимизации картинок, а о том, как проект в плюс вывести, чтобы были финансы на хранение данных.

Почему Redux так популярен?

В случае Redux всякие сайд-эффекты типа запросов к API делаются в экшенах. А где при использовании Context API их правильно делать?

Как организовать грамотную доставку образа PHP приложения если необходим общий volume?

они ведь при условном docker pull не изменят ничего в папке на хосте

docker pull просто затягивает свежий образ, если он есть. На содержимое папки, указанной в volumes это не влияет. Я имею в виду папку, которая "снаружи". Если вы что-то меняли внутри запущенного контейнера, то эти изменения потеряются при перезапуске.

Как организовать грамотную доставку образа PHP приложения если необходим общий volume?

Александр Карпов, вообще есть правило, что один процесс на один контейнер, поэтому все в один образ тащить - плохая идея.

как выживают нормальные боевые проекты

В тех проектах, которые я видел, фронт и бэк разные репозитории имели, а код запихивался в образ при сборке. В образ, отнаследованный от Nginx, запихивался собранный вебпаком js, например (если собирается образ для фронтенда). Контейнеры управляются с помощью Nomad.
Всё, я, кажется, понимаю, в чем у вас проблема. Попробуйте так: если в Dockerfile вообще никакой код в образ не пихать в момент сборки образа, а указать нужные папки в volumes в docker-compose.yml для Nginx и Php контейнеров, то разве не пашет? Грубо говоря, так:

version: '3'
services:
  app:
    image: php-fpm
    volumes:
      - ./:/var/www # Пропихиваю код
  nginx:
    image: nginx
    volumes:
      - ./static:/var/www # Пропихиваю папку со статикой
  apache:
    image: apache
    links:
    - "app"

В секции, отвечающий за контейнер с Apache я не просто так не указал папку с кодом, а потому, что она ему не нужна. Если Вам не совсем понятно, как образ Apache увидит запущенный php, то в конце Dockerfile образа с php-fpm надо указать две команды:

EXPOSE 9000
CMD ["php-fpm"]

А в docker-compose для контейнера Apache надо указать, соответственно, links, и Apache настроить на TCP-сокет php-fpm контейнера с ним, указав порт 9000. Как-то так:

ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://app:9000/path/to/your/documentroot/$1

Как организовать грамотную доставку образа PHP приложения если необходим общий volume?

Александр Карпов, а, Вы про это) Я решил, что речь о всяких загруженных пользователями картинках и т.п. Js/css-файлы я бы вшивал в образ при сборке. Если у вас все в одном репозитории (php и фронтенд), то при сборке образов, которым требуется либо php, либо что-то из js/css, пропихивал бы туда все содержимое репозитория проекта (несмотря на то, что образу с Nginx php-скрипты не нужны). Но не через volumes докер-композа. То есть если у приложения сменились стили, то пересобираете образ, выставляете ему новый тег. Если нужно откатиться, то используете образ с предыдущим тегом.

Как организовать грамотную доставку образа PHP приложения если необходим общий volume?

Александр Карпов, так вы в вопросе спрашиваете про доставку кода. Код я бы вшивал в образ. Если речь о статике, то либо ее хранить в S3, либо пропихивать через volumes. Причем для всех контейнеров, кроме того, где php, для volumes статики надо указать :ro (readonly):

volumes:
    media:/app/media:ro

Разумно ли конвертировать изображения в base64 и сохранять в базу?

Нет, не разумно. Хранить картинки в базе - плохая идея.

Как написать быстрый парсер на PHP?

PendalF89, для работы с базой пул коннектов используете?

Повлияет ли на выдачу сайта покупка сайта смежной тематики?

Я думаю, это не даст ничего. Тем более, что 15000 в месяц - это всего 500 человек в день. Это ж ни о чем.

Для веб разработки php важнее остальных ЯП?

но в отличии от PHP более мощный позволяющий например конвертировать/обрабатывать файлы на стороне сервера.

А php не может, да?)

Apache php-fpm изолирование сайтов?

kiranananda, ftp-то Вам зачем?