Но про ангуляр я вчера картинку вроде находил

тип angular-forlmly

Но про ангуляр я вчера картинку вроде находил

для приложенек где много форм норм. Админки всякие, бизнес прилажки

Соната хорошо, если ты во фронтенд вообще не можешь. Но там полный ад с формтайпами, и знать надо дофига

Рест фигануть куда проще, хотя вообще тот же мармелабовский реактовый админ-интерфейс капец как схож по структуре с сонатой. Понятно почему, потому что бизнес-задача одна — CRUD

Но про ангуляр я вчера картинку вроде находил

то что ангуляр тормозит, это вина тех кто его готовит) сам фрейм оптимизирован нормально

я сча с angular2 балуюсь

когда люди доктрину юзают в цикле, это ж не доктрина виновата?

Вот для справки https://github.com/marmelab/admin-on-rest

блин, раз есть возможность, то спрошу: если мы выносим логику из контроллеров, то где хранить доменную логику? я прикинул, что доменные менеджеры под каждую сущность - это перебор, + не всегда ясно, какому менеджеру присваивать метод. начал копать глубже, вышел на DDD, CQRS и т.п. Туда копать?

когда люди доктрину юзают в цикле, это ж не доктрина виновата?

Прям интересно стало, как именно

то есть накатать рест и потом к нему прикрутить админку?

Вот для справки https://github.com/marmelab/admin-on-rest

graphql для crud тож норм

блин, раз есть возможность, то спрошу: если мы выносим логику из контроллеров, то где хранить доменную логику? я прикинул, что доменные менеджеры под каждую сущность - это перебор, + не всегда ясно, какому менеджеру присваивать метод. начал копать глубже, вышел на DDD, CQRS и т.п. Туда копать?

доменную логику - в сущностях)

сущности, объекты-значения, сервисы

то есть накатать рест и потом к нему прикрутить админку?

Если охота запариваться за фронтенд — попробуй. Сонату юзать можно, но часто бывает, что хочешь сделать без костылей, и лезешь в доку на два часа. Можно такое же и на JS-админке словить на самом деле

Ну и рест всё равно делать, это тоже косты

Ну и рест всё равно делать, это тоже косты

не большие

блин, раз есть возможность, то спрошу: если мы выносим логику из контроллеров, то где хранить доменную логику? я прикинул, что доменные менеджеры под каждую сущность - это перебор, + не всегда ясно, какому менеджеру присваивать метод. начал копать глубже, вышел на DDD, CQRS и т.п. Туда копать?

http://blog.byndyu.ru/2010/05/domain-driven-design.html вот почитай это и там еще цикл статей

сущности, объекты-значения, сервисы

вот про сервисы подробнее бы. я уже говорил про доменные менеджеры и про их проблемы

Домена, блин. Предметной области же

Доменная печь)

Доменная печь)

домен = предметная область

у всех разное понятие "домена", увы)

Печь предметной области, всё правильно :)

вот про сервисы подробнее бы. я уже говорил про доменные менеджеры и про их проблемы

проблема в том что менеджеров быть не должно. Давай лучше на каком-то более конкретном примере

есть вопрос делигирования ответственности

ну мол у тебя есть пачка объектов которые отвечают за маленькие операции/бизнес правила

и тупой менеджер который тупо задает последовательность, флоу

в нем нет if-ов

ну и в сущностях нет геттеров, нет сеттеров

есть только объекты

и операции которые нужно проделать с данными которые хранят объекты

например: public function changePassword(string $oldPassword, string $newPassword, PasswordEncoder $encoder) { if (!$encoder->isValid($this->password, $oldPassword)) { throw new InvalidPasswordException(); } $this->password = $encoder->encode($newPassword); }

один метод вместо какого-то сервиса-менеджера и кучи гетеров сеттеров

проблема в том что менеджеров быть не должно. Давай лучше на каком-то более конкретном примере

ок. есть "группа", в ней "аккаунты" с разными "ролями". задача - создать группу. 1. создается сущность группы с названием. 2. создается сущность аккаунта, в конструкторе у него: текущий "User" (да, речь о Symfony), свежесозданная группа и роль "admin". 3. обе сущности персистятся. затем флаш. итого - два действия, одно зависит от другого.

вся бизнес операция инкапсулирована

> ок. есть "группа", в ней "аккаунты" с разными "ролями". задача - создать группу. почитай про такую штуку как "агрегат сущностей"

попробуй нарисовать граф сущностей в твоей бизнес транзакции и кто кому нужен

что бы сделать дела

и кто будет главным

> 3. обе сущности персистятся. затем флаш. одна сущность добавляется в репозиторий. Флаш в контроллере.

Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit.

т.е. следует копать про DDD?

т.е. следует копать про DDD?

ну книжку Эванса почитать ты должен

но конкретно в этом случае

начни просто с того что подумай

кто в операции главный

может ли группа сама создать аккаунты? какой информации ей не хватает? как собирается граф объектов

1. быстрой мыслью предполагаю, что не может, т.к. при этом в группу придется инжектить фабрику аккаунтов.

ну книжку Эванса почитать ты должен

что за книжка?

DDD, так и называется

я так и не дошел до нее пока)

ну Domain-Driven Development

я уже книгами обложился ?

когда только читать успевать

Может быть сложновата, есть смысл до нее про solid, GRASP почитать)

есть сокращенная версия: DDD Quickly

Может быть сложновата, есть смысл до нее про solid, GRASP почитать)

давай книги )

Ларман)

солид в целом представляю как и что

только принцип лисков меня напрягает

Да, вот от infoq можно ddd quickly

я его не вкурил толком

давай книги )

Дядя боб про solid, ларман про grasp

ERROR: S client not available

что за дядя боб? )

Clean Code

мб имеет смысл FAQ какой-то сделать)

Robert Martin

http://www.williamspublishing.com/Books/978-5-8459-1185-8.html

это?

угу

я аж как-то горд за наших симфонистов. вот сижу уже почти 3 мес в jvm и scala чатиках, за это время ни разу не было упоминаний SOLID, DDD и вообще хоть каких-то вещей из мира ООП. всегда идут какие-то набросы "котлин не нужен", "неосилили скалу", "го гавно", шуточки про пхп и прочий флуд. многие люди там даже не знают кто такой дядюшка боб, фаулер...

я аж как-то горд за наших симфонистов. вот сижу уже почти 3 мес в jvm и scala чатиках, за это время ни разу не было упоминаний SOLID, DDD и вообще хоть каких-то вещей из мира ООП. всегда идут какие-то набросы "котлин не нужен", "неосилили скалу", "го гавно", шуточки про пхп и прочий флуд. многие люди там даже не знают кто такой дядюшка боб, фаулер...

у меня есть гипотиза что толковый скалисты по таким чатикам просто не сидят)

у меня есть гипотиза что толковый скалисты по таким чатикам просто не сидят)

А ты тогда что тут делаешь? Потому что тогда и пхпешники не должны сидеть по чатам

А ты тогда что тут делаешь? Потому что тогда и пхпешники не должны сидеть по чатам

я не скалист а это не чатик по скале

это чатик по php а я дно

у меня есть гипотиза что толковый скалисты по таким чатикам просто не сидят)

да ладно, есть там знаменитые скалисты в чатике. и очень активно сидят

точно так же и в jvm чатике вспомним Баруха, Архипова, Гамова и тд

у меня есть гипотиза что толковый скалисты по таким чатикам просто не сидят)

и где еще тусоваться крутым скалистам? от конфы до конфы передвигаться? на реддите?

в твиттере?

https://github.com/silexphp/Pimple/pull/14/files#diff-553037d9adc48bbece4ab185700cf095

а как себя ведет кложура, помещенная в неймспейс?

как кложура

у нее нет имени

потому неймспейс на нее не влияет

а вот если ты создаешь кложуру в контексте какого-то класса - то.... у тебя есть функция в контексте класса (с доступом к приватному состоянию)

namespace My\OAuth2\Client\Factory; class OAuth2 { public static function getProvidersFactory($providers, $settings) { } } Catchable fatal error: Argument 1 passed to My\OAuth2\Client\Factory\OAuth2::factory() must be an instance of My\OAuth2\Client\Factory\Closure, instance of Closure given, c

private static function factory(Closure $callable)

ты слэшик забыл

\Closure $callable

а еще можешь просто писать

callable $callable

callable is better

?

ну больше рарзрешает

вариантов