-
Notifications
You must be signed in to change notification settings - Fork 39
Open
Labels
enhancementNew feature or requestNew feature or requestquestionFurther information is requestedFurther information is requested
Description
Хотелось бы видеть больше такой информации, как Best/Bad Practices, разборы полётов и тонких моментов.
Вот некоторые вопросы:
-
Entities:
- Чем полезно и стоит ли при использовании связей декларировать в сущностях автогенерируемые поля, например
post_id,user_id - Стоит ли делать сеттеры/геттеры на эти поля? Делать публичными или лучше совместить с сеттерами/геттерами полей
getUser(),setUser() - Если я описываю поле в
camelCase, то Cycle создаёт двойника вunder_scopeи иногда с этим бывают проблемы. Хорошо бы осветить Best/Bad Practices на эту тему.
Я пока пришёл к выводу, что лучше создавать поля в under_scope, а геттеры/сеттеры в camelCase - Тема типизации в сущностях
- Есть поля с автокастом - их можно хорошо протипизировать. То, что не кастуется, походу
string. Json во что-то кастуется? - Есть поля, задающие связи - тут всё не просто - вот тебе, читатель, ссылка на References and Proxies, в phpDoc указывать, например,
@return ArrayCollection|Entity[]. - Правильно ли поля-связи засовывать как параметры в конструктор, если эти связи обязательные (не могут быть null)? Если нет, то при вызове
getUser()вероятен Fatal Erorr, т.к.поле не инициализировано. Может лучше вернуть null из геттара, а в случае записи в БД ждать ошибки из DBAL?
- Есть поля с автокастом - их можно хорошо протипизировать. То, что не кастуется, походу
- Публичные свойства вместо сеттеров/геттеров - каков опыт применения? Почему стоит или не стоит отказаться
- Чем полезно и стоит ли при использовании связей декларировать в сущностях автогенерируемые поля, например
-
Repository:
- Раскрыть тему того, как засунуть свой Repository в свой контейнер.
Например, можно на каждый репозиторий вручную написать фабрику. А можно реализовать такой то интерфейс и подсунуть туда то и при получении схемы Cycle сам задефайнит фабрики для репозиториев. - Лучшие практики на тему того, как разнести репозиторий. Например, для работы с архивными записями постов, я делал так:
final class ArchiveRepository { private PostRepository $postRepo; public function __construct(ORMInterface $orm) { /** @var PostRepository $postRepo */ $postRepo = $orm->getRepository(Post::class); $this->postRepo = $postRepo; } //... }
- Раскрыть тему того, как засунуть свой Repository в свой контейнер.
Возможно то, что я написал, в доке уже есть.. но как-то это сложно всё бывает найти.
Со временем могу пополнять список вопросов
wolfy-j, thenotsoft and Concentum
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requestquestionFurther information is requestedFurther information is requested
Type
Projects
Status
Backlog