Спорное утверждение. Ветка develop по сути содержит ветки которые попадут в следующий релиз. Можно ветку назвать release или release-1.2.3 по номеру версии следующего релиза. Можно для релиза создать отдельный тикет и соответственно ветку назвать по номеру тикета как и все обычные ветки.
Суть этой ветки в том что бы всегда видеть что будет в следующем релизе. Например показать спонсорам набор фич, лишний раз протестировать на совместимость фич, можно отдать на тестирование на сторону. Если ветки develop не будет, то придется каждый раз мерджить все ветки как появится необходимость и каждый раз по новой решать конфликты.
Если в качестве пререлизной ветки использовать master, то будут проблемы с выкатыванием хотфиксов без фич которые уже смерджены в master
Также частым решением бывает создание сайта разработки dev.example.com. Если example.com эквивалентен ветке master, то для сайта dev.example.com выбирают эквивалентом ветку develop. Если мы будем называть ветку release-1.2.3 или issue-123, то будут проблемы с настройкой автодеплоя сайта dev.example.com так как ветка постоянно меняется.
Это что касается web. Для других проектов это может быть не актуально и там возможно и правда не нужна ветка develop.
Из собственного опыта скажу, что при разработке библиотек, ветка develop действительно только мешает, а при разработки крупных сайт-проектов сильно спасает.
Получается если создать ветку Б из ветки А, то они будут эквевалентны и будет сложно понять что это ветка Б сделана из А или А из Б. То есть какая из веток является изначальной и соответственно к какой ветке относятся сделанные ранее коммиты. Но если ветки эквевалентны, то какая принципиальная разница какая из них изначально созданная?
Что вы в корзину положите одно яблоко, что одно яблоко положите в корзину, все равно в корзине будет одно яблоко.
То же самое происходит если создать ветку Б из корня ветки А и смерджить в нее ветку А, но при условии что ветка А не участвовала в других мерджах. В моем случае это ветки issue-345 и issue-456 с общими коммитоми 916908b и 4310c9e. А вот с веткой issue-3 это уже не работает так как ветки issue-1 и issue-2 уже участвовали в мерджах.
У меня нет под рукой SVN чтоб проверить, но думается мне что там будет похожая картина
Забыл сказать. Проблемы есть только с тестированием, когда нужно отдать задачу на тестирование тестировщикам.
По правильному нужно тестировать задачу сначала отдельно (как отдельную ветку), а потом сливать в develop и тестировать еще раз на совместимость с другими задачами в develop.
У нас тестировщики были ленивые и тестировали сразу develop что изрядно усложняло разработку и ветвление в git.
После удаления ветки удаляется только метка ветки, а коммиты никуда не деваются. Они все еще висят в истории как отдельная ветка (если конечно ветку смерджили куда-то с флагом --no-ff). Я даже больше скажу. Можно восстанавить ветку после удаления и начать работать с того же места на котором остановился (доводилось такое делать). И все ветки прекрасно видно в истории даже после их удаления. Сами полистайте историю.
Если вам лень читать статью, то объясню все на пальцах:
Ветка master всегда эквевалентна продакшену
Ветка develop предназначена для разработки.
Перед релизом обязательно сливаться в master.
Также полезным будет слить master в develop.
Если develop не сливать в master, то через несколько итераций расхождение веток может стать критическим (сталкивался с таким).
Ветка issue-123 создается по тикету #123.
Создается из master и мерджится в develop.
Если ей для работы нужны другие задачи, то они мерджатся в нее.
Ни в коем случае нельзя в нее мерджить develop ибо может потребоваться выкатить эту задачу до полного релиза с мерджем develop в master, а в этот момент в develop может быть еще не доработанная или не до тестированная фича.
Ветка fix-456 hotfix по тикиту #456 со срочными правками.
Создается из master и мерджится в master, develop и другие активные ветки по необходимости.
Далее выкатывается master с hotfix-ами.
Ветку develop не трогаем.
Работаю по этой схеме уже несколько лет в разных компаниях и ни каких проблем.
Начнем с того что у нас 48000 пользователей и 3000 каналов. Это 16 пользователей на канал :)
Я так понимаю что зарегистрированных пользователей 48к, а устройств (тоесть реально пользующихся) 33к. А так как ваше решение мультиплатформенное и продвигается именно как такое, то количество реальных пользователей значительно меньше чем устройств.
А и еще не ответил по поводу фразы «либо свое приложение либо никакое» для охвата всех платформ нужно нанять штат программистов и платить им деньги чтобы они все это поддерживали, купить сервера для отправки и тд.
Естественно дороже, но и профит не 200 человек, а тысячи или даже милионы пользователей. Пользователей с которыми мы имеем двустороннюю связи и на которых мы можем раельно зарабатывать.
Я не просто так упомянул другие приложения. Как вы думаете, почему у приложения YouTube или Facebook пользователей больше чем у вас? Ладно, возмем для урощения новостные приложения: РБК, RT, РИА и т.д.
Почему у них пользователей больше чем у вас? Да потому что не PUSH-ем единым живы.
Ваше решение хорошо подходит для блогеров у которых нет денег, которым плевать не пристиж и для которых PUSH это только дополнительная плюшка как RSS.
Какое же это одно приложение? Это целый зоопарк приложений. Платформа конечно одна, но чтобы ей пользоваться нужен зоопарк. Это савсем не здорово.
Если пользователю нужно что-то ставить чтоб пользоваться сервисом это уже плохо. С таким же успехом можно разработать приложение на дисктоп. А лучше вообще, выдать каждому пользователю брендированные, персональные телефоны, которые только и делают что показывают наши замечательные push уведомления. Я утрирую конечно, но суть вы уловили?
Пользоваться нужно либо нативными уведомлениями либо никакими. А для мобильных устройств нужно разрабатывать полноценное персональное приложение, которое кроме всего прочего ещё и уведомления отправляет. Пример тот же Вконтакте, Файсбук, Ютуб и т.д.
Ещё хорошей практикой является не рассылка спам уведомлений всем и все без разбора, а отправка персоналезированных сообщений, а они завязаны на бизнеслогике проекта. Ваш проект позволяет такое?
Ах, да. Савсем забыл. Если верить вашей же статистике то у вас в среднем 10 человек на канал. Это савсем не вдохновляет.
Да, конечно, но остальные коммиты будут в ветке. В network будут отдельно коммиты сделанные в мастер и отдельно коммиты сделанные в ветку + мердж коммит.
А для того что бы по номеру коммита из истории в мастере определить из какой ветки он в нее пришел достаточно посмотреть вверх по истории до ближайшего мержда. Ну и конечно ветку нужно называть по номеру тикета.
Если стоит задача просто упорядочить код репозитория, разделить запросы фронта, бэка и т. п. для более удобной работы с ними, то можно просто использовать трейты.
@Fesor уже предложил решение получше. Использовать спецификацию из DDD (пример)
В общем и в целом, выделение кода приложения в отдельные бандлы имеет смысл только если они не зависят друг от друга
Естественно речь шла о полном разделении и минимизации связей между бандлами. В одном из докладов, Олег Зинченко говорил о том что разделение приложения на несколько бандлов, керналов и фронт контроллеров позволит легко управлять отдельно каждой частью проекта независимо. Так же должна повысится читаемость и организованность кода по сравнению хранением всего проекта в одном бандле. И за счет разделения мы значительно уменьшим количество сервисов в каждой части приложения что тоже приведет к своим плюсам.
Вы вселяетесь в отель, а там говно по стенам, но жить-то можно, все ж живут
Скорее так:
Я видел эти отели. Там грязно. Я видел волос на полу и складку на постеле. В ванной небыло одноразовых тапочек. А полотенце не было сложено в виде лебедей. А ещё халат висел не на вешелке. А ночью я видел свет из коридора в щель под дверью.
Отели это зло. Я лучшие по своему. В картонной коробке на улице. Она продувается, в ней холодно, жёстко и она намокает и разваливается от дождя. Но это моя коробка. Я сам её собирал. Я сам заклеивал все дыры скотчем. Я знаю её как облупленную. А в этих ваших отелях даже щель под дверью закрыть нечем.
Шаблон спецификация не регламентирует то как вы выборки делаете. И я не про Criteria доктриновскую. У меня спецификации работают с query builder-ом.
Я думал вы про шаблон проектирования, а тут выходит всё ещё хитрее. Не поделитесь примерчиком?
Мы сделали отдельно отдел фронтэндщиков что бы похапэшники не лезли во фронтэнд. И я могу сказать что это весьма профитно.
Ну дык. Конечно. Я версткой занимаюсь только на своём проекте. На работе уже несколько лет во фронтенд залезаю только чтоб что-то быстро поправить когда верстальщики заняты или в админке нужно какую-то плюшку прикрутить побыстрому.
А что есть "оптимально"? Схема там генерится так как описано, это все же не полностью все на магии.
О, там много чего:
индексы нужно описывать в аннотациях. Мелочь, а не приятно
FOREIGN KEY доктрина не создает или я не нашел как это сделать
Хотябы на уровне таблицы нужно ставить кодировку. Не стоит расчитывать на настройки сервера.
кодировку для полей ставить тоже не очень удобно.
комментарии к полям таблицы и самой таблицы добавляются не очень красиво. В русскоязычных проектах я всегда добавляю комментарии, чтоб любой разработчик, не знакомый с проектом, мог по базе понять как всё устроено.
для интов тоже нужно указывать длинну. Если мы точно знаем что в конкретном случае число не будет больше 200, то нет необходимости использовать INT, тут больше подойдет TINYINT(2) UNSIGNED.
если в базе используется TINYINT (2) доктрина всё равно преобразует его в boolean при генерации маппинга.
для представления boolean в бд доктрина использует антипаттерн TINYINT(1) со значениями 1 и 0. Во первых в MySQL есть тип данных BOOLEAN который экономичней, но имеет значения TRUE и NULL, что не совсем логично(давно не заглядывал в доку) сейчас этого типа уже нет, а BOOL это синоним к TINYINT. В TINYINT(1) в действительности можно записать не только 0 и 1, а можно записать числа 0-9 и NULL, а если не стоит UNSIGNED то и отрицательные числа замечательно записываются. Это звучит смешно, но мне один раз достался проект в котором у пользователей в поле gender были значения 0, 1, 2, 3, 4 и NULL. Назначение некоторых значений не знали даже самые старые члены команды. И для каждого пола 10к+ пользователей. Поэтому я предпочитаю использовать тип ENUM. Он занимает столько же места что и TINYINT, но чётко ограничивает набор доступных значений и делает их более информативными. Согласитесь, status 0/1 выглядит менее информативно чем status enabled/disabled? И расширять такие статусы проще. Были у меня случаи когда при изменении требований boolean превращался в enum.
Все это можно обойти. Сконфигурировать в аннотациях, скорректировать в DBAL и тд, но на мой взгляд лучше если будет нормальная, легко читаемая бд и не надо лезть в код проекта каждый раз когда что-то не понятно в бд. И имея на руках одну только базу можно легко написать новый проект на другом языке.
мне нравится паттерн спецификация
Согласе. Интересный паттерн. Хотя он решает только треть задач ставящихся перед репозиторием. Он позволяет управлять фильтрами, но запросы это не только выражение where, но и джойны, группировки, хевинги, кастомезированные селекты и т.д. Видимо нужно создавать классы для отдельных запросов, но что тогда делать с внешними зависимостями.
Если это было на тех выходных, то может даже я это и говорил)
Я смотрел доклад Олега Зинченко опубликованнный в 2014 году. На прошлой неделе что-то я таких замечаний не слышал.
У меня бэкэнд это чисто HTTP API, а админки, круды и т.д. у меня сделаны на ангулярах.
Это хорошо когда есть сильные фронтенд программисты. Я таким похвастаться не могу. Сам во фронтенд стараюсь не лезть.
В дрогой статье про неправильный путь в PHP вы писали что сначала создаете объектную структуру в соответствии с бизнес логикой, описваете мапинг и диктрина сама билдит вам схему бд.
Вы не обращали внимание на то что схема генерируемая доктриной сильно не оптимальна?
я уже пробовал "ваш" подход на протяжении 3-х лет и "мой" подход на протяжении последнего года
Не удивлен. Потому я и считаю что каждый должен заниматся своей задачей. Имхо сериализация и десериализация не относятся к задачам модели.
Я допускаю использование бандлов если в будущем есть шанс разделить все на микросервисы
Я скорей имел в виду разделение на окружения и выделение отдельных фронт контроллеров. То есть получаются практически полностью разные приложения в одном проекте. При необходимомти их можно полностью разделить. Это позволяет нам разделить конфигурации окружений, разделить набор сервисов, разделить модели и репозитории.
Пример конкретной проблемы. Сейчас переписываю один проект с 0 и в репозиториях у меня получается каша. Там есть методы которые используются только в админке, есть методы которые есть только в консоли, методы которые используются только на фронте и методы которые используются для мигрирования данных со старого проекта на новый. Всё это разные методы и ни как не пересикаются.
И вот эта каша мне савсем не нравится. Есть у вас какие мысли на этот счёт?
никаких CoreBundle-в
Инфраструктуру выносить в бандлы — очень удобно. Например UploadBundle и т.д.
Полностью согласен. В одном из дакладов на framework day тоже говорили что CoreBundle это зло. Только я предпочитаю компоненты выносить не просто в бандлы, а в отдельные Composer пакеты.
Короч вы предлагаете вместо "давайте разберемся что такое ООП, как проектировать системы, как использовать подходы и инструменты те что надо и там где это надо" фигачить все как тупой CRUD.
Почти. Я "предлагаю" разбиратся в ООП и не использовать CRUD там где это действительно необходимо. На мой взгляд это действительно необходимо на фронте. В админке же работает ограниченный набор людей которые сидят рядом со мной и которым я лично могу надавать по шапке в случае чего.
Учитывая мощь Sonata, грешно не воспользоваться ею хотябы на первых этапах запуска проекта.
Спорное утверждение. Ветка develop по сути содержит ветки которые попадут в следующий релиз. Можно ветку назвать release или release-1.2.3 по номеру версии следующего релиза. Можно для релиза создать отдельный тикет и соответственно ветку назвать по номеру тикета как и все обычные ветки.
Суть этой ветки в том что бы всегда видеть что будет в следующем релизе. Например показать спонсорам набор фич, лишний раз протестировать на совместимость фич, можно отдать на тестирование на сторону. Если ветки develop не будет, то придется каждый раз мерджить все ветки как появится необходимость и каждый раз по новой решать конфликты.
Если в качестве пререлизной ветки использовать master, то будут проблемы с выкатыванием хотфиксов без фич которые уже смерджены в master
Также частым решением бывает создание сайта разработки dev.example.com. Если example.com эквивалентен ветке master, то для сайта dev.example.com выбирают эквивалентом ветку develop. Если мы будем называть ветку release-1.2.3 или issue-123, то будут проблемы с настройкой автодеплоя сайта dev.example.com так как ветка постоянно меняется.
Это что касается web. Для других проектов это может быть не актуально и там возможно и правда не нужна ветка develop.
Из собственного опыта скажу, что при разработке библиотек, ветка develop действительно только мешает, а при разработки крупных сайт-проектов сильно спасает.
Если вы ну совсем никак не можете разобраться в своих коммитах, пропишите хук в PROJECT/.git/hooks/prepare-commit-msg.
Этот добавит
#<BRANCH_NAME>в конце коммита.Называйте ветки по номеру задачи или по номеру задачи с префиксом
issue-и будет вам счастье.GitHub, GitLab и Bitbucket автоматом подцепят тикеты
Ну и не забываем про
А в чем проблема?
Не сталкивался с таким и даже слабо себе это представляю.
Протестировал немного.
Да, сделать такое можно.
Получается если создать ветку Б из ветки А, то они будут эквевалентны и будет сложно понять что это ветка Б сделана из А или А из Б. То есть какая из веток является изначальной и соответственно к какой ветке относятся сделанные ранее коммиты. Но если ветки эквевалентны, то какая принципиальная разница какая из них изначально созданная?
Что вы в корзину положите одно яблоко, что одно яблоко положите в корзину, все равно в корзине будет одно яблоко.
То же самое происходит если создать ветку Б из корня ветки А и смерджить в нее ветку А, но при условии что ветка А не участвовала в других мерджах. В моем случае это ветки issue-345 и issue-456 с общими коммитоми 916908b и 4310c9e. А вот с веткой issue-3 это уже не работает так как ветки issue-1 и issue-2 уже участвовали в мерджах.
У меня нет под рукой SVN чтоб проверить, но думается мне что там будет похожая картина
Забыл сказать. Проблемы есть только с тестированием, когда нужно отдать задачу на тестирование тестировщикам.
По правильному нужно тестировать задачу сначала отдельно (как отдельную ветку), а потом сливать в develop и тестировать еще раз на совместимость с другими задачами в develop.
У нас тестировщики были ленивые и тестировали сразу develop что изрядно усложняло разработку и ветвление в git.
Вы что, не читали статью по ссылке?
После удаления ветки удаляется только метка ветки, а коммиты никуда не деваются. Они все еще висят в истории как отдельная ветка (если конечно ветку смерджили куда-то с флагом
--no-ff). Я даже больше скажу. Можно восстанавить ветку после удаления и начать работать с того же места на котором остановился (доводилось такое делать). И все ветки прекрасно видно в истории даже после их удаления. Сами полистайте историю.Если вам лень читать статью, то объясню все на пальцах:
Перед релизом обязательно сливаться в master.
Также полезным будет слить master в develop.
Если develop не сливать в master, то через несколько итераций расхождение веток может стать критическим (сталкивался с таким).
Создается из master и мерджится в develop.
Если ей для работы нужны другие задачи, то они мерджатся в нее.
Ни в коем случае нельзя в нее мерджить develop ибо может потребоваться выкатить эту задачу до полного релиза с мерджем develop в master, а в этот момент в develop может быть еще не доработанная или не до тестированная фича.
Создается из master и мерджится в master, develop и другие активные ветки по необходимости.
Далее выкатывается master с hotfix-ами.
Ветку develop не трогаем.
Работаю по этой схеме уже несколько лет в разных компаниях и ни каких проблем.
Я так понимаю что зарегистрированных пользователей 48к, а устройств (тоесть реально пользующихся) 33к. А так как ваше решение мультиплатформенное и продвигается именно как такое, то количество реальных пользователей значительно меньше чем устройств.
Естественно дороже, но и профит не 200 человек, а тысячи или даже милионы пользователей. Пользователей с которыми мы имеем двустороннюю связи и на которых мы можем раельно зарабатывать.
Я не просто так упомянул другие приложения. Как вы думаете, почему у приложения YouTube или Facebook пользователей больше чем у вас? Ладно, возмем для урощения новостные приложения: РБК, RT, РИА и т.д.
Почему у них пользователей больше чем у вас? Да потому что не PUSH-ем единым живы.
Ваше решение хорошо подходит для блогеров у которых нет денег, которым плевать не пристиж и для которых PUSH это только дополнительная плюшка как RSS.
Порадовала запись на сайте:
И ниже пачка ссылок.
Какое же это одно приложение? Это целый зоопарк приложений. Платформа конечно одна, но чтобы ей пользоваться нужен зоопарк. Это савсем не здорово.
Если пользователю нужно что-то ставить чтоб пользоваться сервисом это уже плохо. С таким же успехом можно разработать приложение на дисктоп. А лучше вообще, выдать каждому пользователю брендированные, персональные телефоны, которые только и делают что показывают наши замечательные push уведомления. Я утрирую конечно, но суть вы уловили?
Пользоваться нужно либо нативными уведомлениями либо никакими. А для мобильных устройств нужно разрабатывать полноценное персональное приложение, которое кроме всего прочего ещё и уведомления отправляет. Пример тот же Вконтакте, Файсбук, Ютуб и т.д.
Ещё хорошей практикой является не рассылка спам уведомлений всем и все без разбора, а отправка персоналезированных сообщений, а они завязаны на бизнеслогике проекта. Ваш проект позволяет такое?
Ах, да. Савсем забыл. Если верить вашей же статистике то у вас в среднем 10 человек на канал. Это савсем не вдохновляет.
на мой взгляд ничего сложного нет
https://habrahabr.ru/post/106912/
Да, конечно, но остальные коммиты будут в ветке. В network будут отдельно коммиты сделанные в мастер и отдельно коммиты сделанные в ветку + мердж коммит.
А для того что бы по номеру коммита из истории в мастере определить из какой ветки он в нее пришел достаточно посмотреть вверх по истории до ближайшего мержда. Ну и конечно ветку нужно называть по номеру тикета.
https://habrahabr.ru/post/106912/
А чем не устроил TortoiseGit? TortoiseSvn в туже степь. Можно еще gui из PhpStorm, но я лично gui не использую. Мне консоль удобнее.
В гите можно мерждить ветку с флагом
--no-ffи тогда в network будет видно откуда коммиты пришли.@Fesor уже предложил решение получше. Использовать спецификацию из DDD (пример)
Естественно речь шла о полном разделении и минимизации связей между бандлами. В одном из докладов, Олег Зинченко говорил о том что разделение приложения на несколько бандлов, керналов и фронт контроллеров позволит легко управлять отдельно каждой частью проекта независимо. Так же должна повысится читаемость и организованность кода по сравнению хранением всего проекта в одном бандле. И за счет разделения мы значительно уменьшим количество сервисов в каждой части приложения что тоже приведет к своим плюсам.
Скорее так:
Я видел эти отели. Там грязно. Я видел волос на полу и складку на постеле. В ванной небыло одноразовых тапочек. А полотенце не было сложено в виде лебедей. А ещё халат висел не на вешелке. А ночью я видел свет из коридора в щель под дверью.
Отели это зло. Я лучшие по своему. В картонной коробке на улице. Она продувается, в ней холодно, жёстко и она намокает и разваливается от дождя. Но это моя коробка. Я сам её собирал. Я сам заклеивал все дыры скотчем. Я знаю её как облупленную. А в этих ваших отелях даже щель под дверью закрыть нечем.
ну вот. пиарились, пиарились и тут выясняется что я не я, корова не моя.
это называется аудит безопасности и стоит он очень приличных денег
да, до вас походу вообще ничего не доходит.
лишь бы ляпнуть какую фигню без хоть малейшего понимания вопроса
и пишете еще большую помойку, но свою. родная помойка не пахнет
Да выложите вы уже ваш говнокод. Мы найдем в нем 100500 дыр и багов и тема "фраймворк vs самопис" будет закрыта.
PS: и не надо повторяться что вы не готовы делиться своим говном
Библиотеку видел, но дальше readme не ушёл и про QueryModifier не прочитал. Спасибо
Я думал вы про шаблон проектирования, а тут выходит всё ещё хитрее. Не поделитесь примерчиком?
Ну дык. Конечно. Я версткой занимаюсь только на своём проекте. На работе уже несколько лет во фронтенд залезаю только чтоб что-то быстро поправить когда верстальщики заняты или в админке нужно какую-то плюшку прикрутить побыстрому.
О, там много чего:
Во первых в MySQL есть тип данных BOOLEAN который экономичней, но имеет значения TRUE и NULL, что не совсем логично(давно не заглядывал в доку) сейчас этого типа уже нет, а BOOL это синоним к TINYINT. В TINYINT(1) в действительности можно записать не только 0 и 1, а можно записать числа 0-9 и NULL, а если не стоит UNSIGNED то и отрицательные числа замечательно записываются. Это звучит смешно, но мне один раз достался проект в котором у пользователей в поле gender были значения 0, 1, 2, 3, 4 и NULL. Назначение некоторых значений не знали даже самые старые члены команды. И для каждого пола 10к+ пользователей. Поэтому я предпочитаю использовать тип ENUM. Он занимает столько же места что и TINYINT, но чётко ограничивает набор доступных значений и делает их более информативными. Согласитесь, status 0/1 выглядит менее информативно чем status enabled/disabled? И расширять такие статусы проще. Были у меня случаи когда при изменении требований boolean превращался в enum.Все это можно обойти. Сконфигурировать в аннотациях, скорректировать в DBAL и тд, но на мой взгляд лучше если будет нормальная, легко читаемая бд и не надо лезть в код проекта каждый раз когда что-то не понятно в бд. И имея на руках одну только базу можно легко написать новый проект на другом языке.
Согласе. Интересный паттерн. Хотя он решает только треть задач ставящихся перед репозиторием. Он позволяет управлять фильтрами, но запросы это не только выражение where, но и джойны, группировки, хевинги, кастомезированные селекты и т.д. Видимо нужно создавать классы для отдельных запросов, но что тогда делать с внешними зависимостями.
Я смотрел доклад Олега Зинченко опубликованнный в 2014 году. На прошлой неделе что-то я таких замечаний не слышал.
Это хорошо когда есть сильные фронтенд программисты. Я таким похвастаться не могу. Сам во фронтенд стараюсь не лезть.
В дрогой статье про неправильный путь в PHP вы писали что сначала создаете объектную структуру в соответствии с бизнес логикой, описваете мапинг и диктрина сама билдит вам схему бд.
Вы не обращали внимание на то что схема генерируемая доктриной сильно не оптимальна?
Не удивлен. Потому я и считаю что каждый должен заниматся своей задачей. Имхо сериализация и десериализация не относятся к задачам модели.
Я скорей имел в виду разделение на окружения и выделение отдельных фронт контроллеров. То есть получаются практически полностью разные приложения в одном проекте. При необходимомти их можно полностью разделить. Это позволяет нам разделить конфигурации окружений, разделить набор сервисов, разделить модели и репозитории.
Пример конкретной проблемы. Сейчас переписываю один проект с 0 и в репозиториях у меня получается каша. Там есть методы которые используются только в админке, есть методы которые есть только в консоли, методы которые используются только на фронте и методы которые используются для мигрирования данных со старого проекта на новый. Всё это разные методы и ни как не пересикаются.
И вот эта каша мне савсем не нравится. Есть у вас какие мысли на этот счёт?
Полностью согласен. В одном из дакладов на framework day тоже говорили что CoreBundle это зло. Только я предпочитаю компоненты выносить не просто в бандлы, а в отдельные Composer пакеты.
Почти. Я "предлагаю" разбиратся в ООП и не использовать CRUD там где это действительно необходимо. На мой взгляд это действительно необходимо на фронте. В админке же работает ограниченный набор людей которые сидят рядом со мной и которым я лично могу надавать по шапке в случае чего.
Учитывая мощь Sonata, грешно не воспользоваться ею хотябы на первых этапах запуска проекта.