Хорошо, если класса два. В противном случае может появиться
а)объект-свалка
б)сотня мелких объектов за которыми сложно уследить
Мне по душе не распылять функциональность относящуюся к конкретным доменам, ведь, зачастую, мы достаточно редко работаем с сушьностями вне контекста их доменов
Абсолютно верно. Он и будет являться службой в тех случаях, когда мы проводим какие-то операции над доменным объектом, в данном случае пользователем, например: показать все заказы пользователя, показать скидочные карты пользователя и т.д.
Все методы такого рода не содержат хитрой логики а проксируют запросы к целевым доменам лишь декорируя их.
public function getOrders()
{
return Orm::find('Order', [ ['user_id', $this->getId()] ]);
}
Цель манипуляций- простота и ясность бизнес-логики.
Ни капли. Пользователь является доменом (хозяином) для своих заказов и получить их от него самого- вполне логично. Так или иначе- всё зависит от цели приложения.
Не стоит принимать это столь близко к сердцу ) На мой взгляд это нормальная реакция огромного и постоянно растущего рынка.
Если рассматривать фреймворк как программный пакет стоящий на ряду с офисом или фотошопом, то и вовсе пропадают сомнения в естественности появления такой ниши узко профилированных специалистов. Я уверен, что ваш бухгалтер не пишет макросы для EXCEL а аккаунт менеджер не коммитит фичи для CRM.
Делайте всё в последний момент — и риск что-то переделывать будет значительно ниже!
Не самый лучший совет, если честно. Если бы мне так говорили мои исполнители, то они бы «делали всё в последний момент» без меня.
Или есть еще риск что никогда не сделаете и будет поздно.
Если что-то не было сделано, значит это не было крайне необходимо. Следовательно — это была лишняя работа =)
По аналогии с утверждением о том, что всё в мире днржится на скотче, супер-клее и пластиковых стяжках, уже скоро можно будет говорить, что всё в мире сделано 3D принтером или подобным образом =)
На мой взгляд, подобные вопросы призваны помочь понять работодателю на сколько глубоко знание, по большей мере, семантики языка. А то как вы его примените- другое дело:)
а)объект-свалка
б)сотня мелких объектов за которыми сложно уследить
Мне по душе не распылять функциональность относящуюся к конкретным доменам, ведь, зачастую, мы достаточно редко работаем с сушьностями вне контекста их доменов
Все методы такого рода не содержат хитрой логики а проксируют запросы к целевым доменам лишь декорируя их.
Цель манипуляций- простота и ясность бизнес-логики.
Если рассматривать фреймворк как программный пакет стоящий на ряду с офисом или фотошопом, то и вовсе пропадают сомнения в естественности появления такой ниши узко профилированных специалистов. Я уверен, что ваш бухгалтер не пишет макросы для EXCEL а аккаунт менеджер не коммитит фичи для CRM.
и
немного контрастирует, вам так не кажется =)
Если что-то не было сделано, значит это не было крайне необходимо. Следовательно — это была лишняя работа =)
<a target="_blank" href="http://task">Начать квест</a>