• Каким классом правильно связать несколько классов?

    Иван Антонов: читайте по Java, их больше, они круче, и знания проэцируются на PHP без проблем. Почитайте Эванса, Фаулера, Боба Мартина...
  • Каким классом правильно связать несколько классов?

    Иван Антонов: ну вы можете начать читать книжки, это тоже дело полезное. А если вам нравится этим заниматься - то почему бы и да?)
  • Какой основной стек технологий на front-end SPA ваша команда использовала за последний год работы на дядю (офис)?

    Digital Brain: сразу видно что вы не работали с ангуляром в плотную. Все же чуть поясню что бы развеять немного смуты вокруг этих холиваров. Вдруг будет полезно.

    Как вы наверное знаете, декомпозиция это одна из самых важных концепций в программировании (и не только). Less is more как говорится. Годами люди старались изолировать поведение из UI-ных компонентов различными способами, что бы позволить разработчику просто и удобно использовать их в большом приложении. Сделать это можно множеством способов, ангуляр просто предоставляет таковой из коробки.

    angular-вские директивы это закономерное развитие идеи декомпозиции UI и изоляции изменений. В купе с введением HTML5, который позволяет нам свободно добавлять свои элементы и атрибуты в разметку, стало возможным изоляция на уровне элементов. Вам нужно вставить дата пикер? Просто пишем

    <date-picker value="{{myValue}}" max-date="1900-01-01" />


    и все, нас не заботит реализация данного элемента. Аналогичный пример - использование video или audio элементов. Они так же имеют поведение, но вас же это не смущает, правда?

    Так как HTML по природе своей декларативен, это так же дает определенную гибкость. Вместо того что бы манипулировать с DOM напрямую, мы можем описать как это должно происходить а компоненты сделают все за нас. Из приятных мелочей, с таким подходом возможно организовать горячую подмену шаблонов (например так возможно делать в reactjs, есть так же эксперементальные реализации для angular 1.x). Что нам дает эта мелочь? Те самые верстальщики, которые будут делать шаблоны, смогут задать какой-то прекондишен в приложении и изменение шаблонов не будет вынуждать нас перезагружать и, как следствие, терять состояние системы. Это экономит массу времени.

    Angular-овские директивы, какими бы страшными и местами убогими они небыли в версии 1.0, дали толчек к развитию концепции web-компонентов. И это вполне себе логичное развитие. ReactJS использует схожий подход, Ember второй вроде бы тоже (не уверен). Angular2 вместо старых директив использует надстроку над web-компонентами. Появились штуки типа Polymer-а (на котором к слову работает google music). Много кто использует тот же Backbone вместе с полимером или реактом.

    ES2015 + Angular 1.4+ весьма похож очертаниями на то, чем будет Angular2. А по поводу "быстро и на коленке всяким верстальщикам" - ну да, тут его так же можно использовать, хотя меня этот вариант сильно расстраивает. Как по мне это неплохой себе HMVC фреймворк.

    Как-то так. Уж простите, меня слишком задевают фразы аля "хак html, шаблоны, верстальщик на коленке"... Справедливости ради стоит заметить что на ангуляре легко все сделать плохо, и у меня уходит довольно много сил что бы не допустить этого в своей команде (когда кто-то новый приходит, уходит где-то месяц что бы человек понял как примерно надо готовить ангуляр). Да я сам много шишек с ним набил пока не разобрался что к чему.
  • Какой основной стек технологий на front-end SPA ваша команда использовала за последний год работы на дядю (офис)?

    Digital Brain: у меня отвращение вызывает backbone, хотя частенько использовал его для реализации моделил в рамках angular приложения.

    А чем вызвано "отвращение"? Вот просто интересно. Посмотрите например на Polymer, это грубо говоря более строгая и продуманная идея директив ангуляра 1-ого. Если руководствоваться именно такой концепцией, разбиение на компоненты (директивы) со своими контроллерами, как самостоятельные мини-приложения, то тогда ангуляр становится няшкой. Где-то с версии 1.3 ангуляр можно уже использовать без отвратительных вещей которые были во времена 1.0 и 1.1. Ну а если используются толстые контроллеры, все разделено максимум на состояния каким-нибудь uiRouter - то тут да... печаль беда.
  • Каким классом правильно связать несколько классов?

    Иван Антонов: нет, в фабрике только логика по созданию объекта, инкапсулирующего все эти атрибуты и т.д. Ее задача - достать из базы все атрибуты и собрать объект-коллекцию. Не более. В целом не загоняйтесь по названиям паттернов, еще успеете. Вы так заранее пытаетесь подогнать свою архитектуру к какому-то паттерну, при том что соблюдая правила SOLID и GRASP вы всеравно придете к чему-то схожему, но с более адекватными названиями.

    Я понимаю зачем вы это делаете, просто такого уже настолько много что становится грустно, что нет ни одной CMS ориентированной исключительно на разработчика. С низким уровнем технического долга и без необходимости ежедневно подпирать все кастылями.

    Я не изобретал его, я сделал что-то подобное

    так может и назовите его OrderRepository? Хотя это мелочи. Но в целом я серьезно приятно удивлен что вы пошли именно этой дорогой.

    Это аналог возвращаемых данных из БД.

    Соль репозитория в том, что именно он хранит данные, а не база данных или что бы то нибыло еще. Он может использовать базу данных как часть своей реализации, но с точки зрения пользовательского кода - без разницы где это все хранится. Единственное что - все это красиво только вместе с unit-of-work и т.д. Иначе возникают сложности.
  • Какой основной стек технологий на front-end SPA ваша команда использовала за последний год работы на дядю (офис)?

    Digital Brain: ну как бы вы же понимаете что это все весьма субъективные вещи? Фреймворки нынче все ближе и ближе друг к дружке по возможностям и архитектуре, и выбор их весьма субъективен. Все же важен не фреймворк а команда.

    Ну и да, скажем в Беларуси найти толковых разработчиков под Angular оказалось не так то просто, хоть их и больше чем под всякие реакты и т.д. На Украине с этим чуть проще. А в России как оно - без понятия. Вообще создается впечатление что из всей этой массы фронтэндщиков которые вечно тусуются на конференция и т.д. интересными являются не такая уж большая часть людей.
  • Каким классом правильно связать несколько классов?

    Иван Антонов: ну и да, Value Object-ы это... собственно объекты-значения. Это какой-то объект с набором свойств, который являет собой одно значение. В нашем случае весь набор дополнительных атрибутов заказа - это одно значение, грубо говоря "набор дополнительных атрибутов". И тип у него может быть например AdditiionalInformation. Это может быть объект-коллекция ваших классов Information, или просто статический объект... или внутри может лежать массив. Тут как говорится вы сами себе хозяин. И тут как раз таки может пригодиться фабрика - что бы генерить это дело и запихивать в сущность при загрузке из базы данных.

    Вариантов масса, но основная идея - спрячьте этот массив в каком-то отдельном классе, который будет уметь работать с кастомными атрибутами. Сущности "заказ" можно просто сказать "прими вот этот набор доп. атрибутов", и ему будет без разницы как оно там что реализовано.
  • Каким классом правильно связать несколько классов?

    Иван Антонов: круто, вы изобрели шаблон "репозиторий". На самом деле я слегка даже удивлен, обычно изобретают всякие богомерзские active record. Читаем про persistence ignorance тогда. И может быть даже стоит взять Doctrine 2.5 в качестве ORM.

    Запросы к БД должны быть вынесены из сущностей, им должно быть плевать как их хранят и где. У вас скажем в тестах они хранятся тупо в массивчике, то есть в in memory репозитории.

    Что до массива непонятных атрибутов - я про поле data у заказа. Оно совершенно нелогично и смотрится весьма странным. Как минимум мне кажется странным давать пользователю CMS возможность накликать атрибуты для заказа. Это конечно круто, но вызовет больше проблем чем пользы. Коль уж делаете что-то интересное, то задумайтесь о том как упростить поддержку системы программисту, таких CMS увы не так много.

    Вместо того что бы обеспечить из админки возможность накликать все и вся, лучше сделать хотя бы одну CMS которую легко поддерживать и расширять функциональность.
  • Каким классом правильно связать несколько классов?

    Иван Антонов: не загоняйтесь вы по шаблонам проектирования. Лучше покройте все юнит тестами, они более наглядно будут говорить что у вас там связанность слишком большая или еще чего. Для всего что вы делаете должна быть причина, изменения которые вы вносите в код должны приносить какую-то ценность. Ну и да, CMS-ка как бы тоже, но я надеюсь что вы все это в плане обучения только пилите.

    Вообще я все же повторюсь - может не надо делать ее настолько уж гибкой и универсатльной? Вместо массива непонятных атрибутов можно использовать 3-4 разных value object-ов реализующих один интерфейс. Это будет покрывать большую часть юз кейсов, ну и сделать это красиво намного проще. А уже на уровне DAO пихать это все в EAV как вы видимо и планировали.
  • Каким классом правильно связать несколько классов?

    Иван Антонов: factory это пораждающий шаблон, он тут к чему? У вас проблема с изменением данных. Лучше расскажите почему у вас вообще возникла необходимость динамически для заказа указывать дополнительную информацию?
  • Как использовать событие onclick?

    Sergey Goryachev: у какой функции? Говоря словами jquery автор хочет:

    $('.z1').on('click', function () {
        $('.z2').trigger('click');
    });
  • Как использовать событие onclick?

    автор хочет затригерить клик по другому элементу.
  • Какие IT специалисты нужны для создания "?" сайта?

    Manoo: в целом солюшен архитектор не нужен, хватит нормального синьера бэкэндера. Так же неплохо мидла-синьер фронтэнд. Архитектор базы данных не особо нужен пока у вас данные не исчисляются терабайтами.
  • Какие IT специалисты нужны для создания "?" сайта?

    Manoo: ну если у вас в списке значится солюшен архитектор, и при этом банально нет QA - у меня складывается впечатление что вы думаете не над MVP а над готовым продуктом напичканным фичами. Добавьте QA и дизайнера в список.
  • В чем проблема при обновлении данных в contoller us?

    JIakki: дело в том что из вашего описания не понятно что не работает. lurkmore.to/%D0%A3%D0%9C%D0%92%D0%A0
  • В чем проблема при обновлении данных в contoller us?

    слишком мало данных. Что именно не так? Дата биндинги не срабатывают? Пробовали $apply у скоупа вызвать?
  • Куда делегировать функции, которые являются частью контроллера, но слишком велики, чтоб оставлять их там?

    Максим: а идея "инкапсулированных сервисов" - тут больше подходят ссылки на слоеные архитектуры, onion architecture, hexagonal architecture и т.д.
  • Куда делегировать функции, которые являются частью контроллера, но слишком велики, чтоб оставлять их там?

    Максим: в том то и вопрос что люди под "моделью" быстро начинают понимать их любимые сущности предоставляемые их любимыми ORM и потом переучивать довольно тяжко.

    Я привел ссылку на неплохой доклад, в котором обзор различных подходов, от тупого круда с толстыми контроллерами до CQRS.