С таким подходом банкротство компании вы тоже подадите как хорошую новость.
Уже пол года не могу поставить новую оперу ни на десктоп ни на планшет. Но столько хороших новостей!
Ваш комментарий стоит всего этого поста. Если бы тот же уровень аргументации был в основном посте… Но увы, в самом посте нет никаких намеков на то что автор хорошо понимает оба паттерны и все вытекающие. «дайте ему шанс, — вам должно понравиться.» звучит как «попробуй, это модно в нынешнем сезоне!»
Рекомендую почитать про Doctrine ORM, и причины почему Symfony сделала по дефолту (вместо Prorel) именно Doctrine.
Насколько я помню, то тут есть нюансы:
* пропел давным давно как мертв (ок, ещё немнго трепыхается, но не суть)
* это произошло ещё в версии 1.2 симфони, когда была доктрина 1.х с реализацией ActiveRecord.
* доктрина единственная серьезная ОРМ которую можно юзать без привязки к фреймворку.
Да, если что я плюсик вашему посту поставил. А мои претензии к автору оригинального поста. Обзор паттернов это хорошо, но «нужно юзать репозиторий, потому что это модно» — явно не аргумент. Хотелось бы, чтобы в РНР сообществе прекратили делить паттерны на модные/не модные.
Во вторых выводы какие-то оч странные. Как будто это мы сами всегда пишем реализации ОРМ.
Если мы работаем с Доктриной, мы вряд ли будем дописывать к ней слой ActiveRecord, работая с ОРМ в других фреймворках (Laravel, Yii), дописывай сколько угодно, а обьект всё равно будет знать как себя сохранить, что совершенно нивелирует паттерн датамаппер. О чем эта статья? Репозитории — это хорошо, ооокей?
— Я кстати подозреваю что статью писал ларавельщик. У них очень печально с аргументацией зачем нужен датамаппер и почему он лучше.
Скептически отношусь к проекту. Да, звучит классно, но какие потери в скорости у нас будут из-за этих черезмерных абстракций и парсинга XML?
А к тому же пока разработчики сделают версию 1.0, уже будет Drupal 9, WordPress 5, Magento 3, Sylius 2, и т.п.
Ну и ниша у проекта достаточно невелика — ентерпрайзные CMS системы. Ничего не сделано для того, чтобы рядовой разработчик омг работать с Symfony CMF. Хотя есть веростяность, что проект чисто академический, ведь до ентерпрайзной CMS ещё идти и идти.
А можете рассказать насколько успешно издательство помогает с промо и маркетингом?
Как вы думаете, справились бы вы сами без издательства, если бы, допустим, выбрали Leanpub?
Ну и по денежным оценкам, написание книги окупило себя?
Если бы ещё автоматическую генерилку уникального CSS локатора — цены бы ему не было :)
А то судя по видео найти XPath это плевое дело, а подобрать к нему CSS это уже сложнее.
Посмотрел на лигу «The League of Extraordinary Packages»
Our Definition of Quality
Ask 100 developers what defines an awesome PHP package and you'll get a lot of different answers. That also sounds like a really long and boring task, so we've decided to come up with a list of rules that make a package awesome:
Follow PSR-2, we use League\ as our PSR-0 namespace.
List on Packagist, we list with league\ as the vendor namespace.
Shove code in a src/ folder.
Write unit tests. Aim for at least 80% coverage for v1.0. DocBlock all the things.
Это просто феерия какая-то. Качество пакета определяется наличием докблоков для всего. При этом фактическая работоспособность пакета их не волнует. Главное, чтобы PSR-всё, а работает ли, нам пофиг :) Такое впечатление, что товарищам важнее показать красивый код, а не результат.
Почему же, достаточно определить свой entity manager.
Ага, можно имплементировать всё методы ентити менеджера, а в итоге написать свою доктрину. Вот только зачем?
Я к тому, что не бывает универсального кода, который учтет абсолютно всё. Пусть использование DI помогает вводить некоторую абстракцию в код, это совершенно не значит, что проектируя с DI мы свободно сможем заменять любые компоненты. Ибо интерфейс ентити менеджера доктрины имплементирует только энтити менеджер доктрины. Если мы меняем ORM, нам недостаточно заменить один сервис на другой, нам нужно переписать большую часть кода.
Подразумевается зависимость от конкретных классов. При описанном подходе во-первых возможно изменить используемый класс через настройки сервис локатора, во вторых явно задать реализацию сервиса (при наличии set- метода).
Когда класс не сферический в вакууме а зависит допустим от модели данных, от библиотек (тех же симфони компонентов, доктрины, etc), то внедряй не внедряй, а иерархию зависимостей потянешь. Если у вас где-то используется entity manager — перенести класс в проект без доктрины уже нельзя.
— Почему класс созданный через фабрику легче подается тестированию?
— И в тесте, подменяя фабрику, мы можем через метод modelFactory()->create() вернуть mock объект, для которого проверим однократный вызов setValue() с ожидаемыми параметрами.
Согласен, речь идет о физической невозможности написать юнит тест. Хотя имхо, фабрика — излишняя абстракция, которая в первую очередь путает разработчика. Что выпрыгнет из черного ящика? А кто его знает. Нужно полезть в код фабрики, посмотреть. Нужно полезть в конфигурацию сервис локатора, посмотреть. Ой, не ту конфигурацию посмотрел. Не то вылезло.
Если реально стоит вопрос тестирования, лучше заюзайте AspectMock.
DI реально усложняет код. Если не планируется замена сервисов, а это случится только если вы пишите расширяемую либу, или фреймворк, то в большинстве случаев DI не нужно. Что точно — не нужен повесместно. Если внядряете DI только ради «тестирования», то нет смысла, продакшн код подгонять под ограничения средств тестирования.
Уже пол года не могу поставить новую оперу ни на десктоп ни на планшет. Но столько хороших новостей!
Но релиза как не было так и нет.
Насколько я помню, то тут есть нюансы:
* пропел давным давно как мертв (ок, ещё немнго трепыхается, но не суть)
* это произошло ещё в версии 1.2 симфони, когда была доктрина 1.х с реализацией ActiveRecord.
* доктрина единственная серьезная ОРМ которую можно юзать без привязки к фреймворку.
Да, если что я плюсик вашему посту поставил. А мои претензии к автору оригинального поста. Обзор паттернов это хорошо, но «нужно юзать репозиторий, потому что это модно» — явно не аргумент. Хотелось бы, чтобы в РНР сообществе прекратили делить паттерны на модные/не модные.
Во вторых выводы какие-то оч странные. Как будто это мы сами всегда пишем реализации ОРМ.
Если мы работаем с Доктриной, мы вряд ли будем дописывать к ней слой ActiveRecord, работая с ОРМ в других фреймворках (Laravel, Yii), дописывай сколько угодно, а обьект всё равно будет знать как себя сохранить, что совершенно нивелирует паттерн датамаппер. О чем эта статья? Репозитории — это хорошо, ооокей?
— Я кстати подозреваю что статью писал ларавельщик. У них очень печально с аргументацией зачем нужен датамаппер и почему он лучше.
А к тому же пока разработчики сделают версию 1.0, уже будет Drupal 9, WordPress 5, Magento 3, Sylius 2, и т.п.
Ну и ниша у проекта достаточно невелика — ентерпрайзные CMS системы. Ничего не сделано для того, чтобы рядовой разработчик омг работать с Symfony CMF. Хотя есть веростяность, что проект чисто академический, ведь до ентерпрайзной CMS ещё идти и идти.
Как вы думаете, справились бы вы сами без издательства, если бы, допустим, выбрали Leanpub?
Ну и по денежным оценкам, написание книги окупило себя?
За месяц можно почти все курсы там пройти.
Кстати, а можно ли поступивший промо-код к старому аккаунту CodeSchool подключить?
Кстати, можете дать ссылку на пример «тяжелых датапровайдеры» в зенде или в симфони.
Если бы ещё автоматическую генерилку уникального CSS локатора — цены бы ему не было :)
А то судя по видео найти XPath это плевое дело, а подобрать к нему CSS это уже сложнее.
Это просто феерия какая-то. Качество пакета определяется наличием докблоков для всего. При этом фактическая работоспособность пакета их не волнует. Главное, чтобы PSR-всё, а работает ли, нам пофиг :) Такое впечатление, что товарищам важнее показать красивый код, а не результат.
Ага, можно имплементировать всё методы ентити менеджера, а в итоге написать свою доктрину. Вот только зачем?
Я к тому, что не бывает универсального кода, который учтет абсолютно всё. Пусть использование DI помогает вводить некоторую абстракцию в код, это совершенно не значит, что проектируя с DI мы свободно сможем заменять любые компоненты. Ибо интерфейс ентити менеджера доктрины имплементирует только энтити менеджер доктрины. Если мы меняем ORM, нам недостаточно заменить один сервис на другой, нам нужно переписать большую часть кода.
Когда класс не сферический в вакууме а зависит допустим от модели данных, от библиотек (тех же симфони компонентов, доктрины, etc), то внедряй не внедряй, а иерархию зависимостей потянешь. Если у вас где-то используется entity manager — перенести класс в проект без доктрины уже нельзя.
Согласен, речь идет о физической невозможности написать юнит тест. Хотя имхо, фабрика — излишняя абстракция, которая в первую очередь путает разработчика. Что выпрыгнет из черного ящика? А кто его знает. Нужно полезть в код фабрики, посмотреть. Нужно полезть в конфигурацию сервис локатора, посмотреть. Ой, не ту конфигурацию посмотрел. Не то вылезло.
Если реально стоит вопрос тестирования, лучше заюзайте AspectMock.
DI реально усложняет код. Если не планируется замена сервисов, а это случится только если вы пишите расширяемую либу, или фреймворк, то в большинстве случаев DI не нужно. Что точно — не нужен повесместно. Если внядряете DI только ради «тестирования», то нет смысла, продакшн код подгонять под ограничения средств тестирования.