• Правильно ли я инициализирую приложение на AngularJS 1.5?

    Максим Иванов:

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


    https://github.com/johnpapa/angular-styleguide/tre...

    Используя геттер для модулей ангуляра.

    А как отвязать jQuery ? Если мне приходится использовать уникальные плагины типа DateTimepicker

    все что работает с DOM напрямую изолируется внутрь директив. Причем так что бы "наружу" оно не лазило. Изолированный говнокод - это нормально. А вот когда он размазан повсюду тонкой дорожкой - как-то не очень.

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


    я невнимательно глянул ваш код. Думал вы всюду Injector иньектите. А вы просто сделали нечитабельно.

    Тут больше напишу. Для начала читаем про ngAnnotate что бы не нужно было руками проставлять аннотации для зависимостей. Ну или же наоборот, руками всегда проставляем зависимости - но не выносим это в некую переменную. Это сильно усложняет код и делает описание зависимостей слабо выраженным.

    Во вторых - либо используйте компоненты либо общие контроллеры. Определитесь уже. Лучше от регистрации контроллеров отдельно вообще отказаться в угоду компонентам. Ну и еще лучше сделать компоненты как можно более тупыми, что бы они получали уже готовые данные через биндинги (пропихивать их через ресолв роутера например) и занимались только отрисовкой UI, в чем собственно задумка и состоит.

    Так же не работайте с $rootScope никогда. Да даже $scope не надо пихать никуда. Только директивам с ним разрешается работать потому что подругому не выйдет (и то есть нюансы). Как минимум есть controllerAs да и компоненты. А вместо ватчеров лучше в контроллере сеттер сделать. Так и проще код выйдет и дебажить удобнее.

    вместо window мне что использовать для "модулей"? сервисы

    у контейнера в ангуляре есть два варианта - .value и .constant. Разберитесь зачем они нужны, в чем между ними разница, и будет прозрение.
  • Правильно ли я инициализирую приложение на AngularJS 1.5?

    MaxKorz:

    а использование window. не является анти-паттерном в ангуляре?

    Смотреть пункт про глобальные переменные. Все что я описал к ангуляру не относится (кроме пункта про то что не надо руками мутировать DOM).

    И все эти es6 импорты... это единственный вариант в es6 инициализировать приложение?

    гуглить бандлеры аля webpack, system.js/bundler или еще какой.

    app.directive('fadebody', fadeInBody)

    Читаем angular styleguide и понимаем что так регистрировать вещи в ангуляре не ок.
  • Как правильно использовать Symfony form с ReactJs?

    Максим Барулин: у вас форма логина, для symfony есть стандартный form login, вам даже не надо ничего пилить.

    p.s. FosUserBundle на самом бесполезен чуть более чем полностью в контексте SPA. Как и большинство бандлов, они расчитаны на использование в контексте web.
  • Как правильно использовать Symfony form с ReactJs?

    Максим Барулин: не нужно вам это. Ну вот от слова вообще. Вы либо делаете SPA полностью на реакте а на бэкэнде оставляете API (без форм и html) либо выносите логин на отдельную страницу и доступ к SPA организуете только для чуваков которые залогинились.
  • Зачем нужен Redux?

    iKBAHT: так, а моя точка зрения как-то противоречит?

    Для меня MVC/MVP/etc это лишь способ отделения UI от приложения. То есть M - приложение, та его часть которая граничит с UI, а VC - это UI layer. Не более. А как строится M - это уже дело приложения. Быть может там гексагональная слоеная архитектура, а может быть просто объект предметной области с DAO. Зависит от сложности приложения.
  • Создать простую админку?

    dhat: ну вот видите - значит нагрузки практически никакой. А зачем тогда форма регистрации?
  • Как спроектировать такое?

    magary4: у вас сейчас как-то все в перемешку.

    У вас проблема с организацией потока управления при использовании асинхронных операций. Это вообще никак не привязано к фреймворкам и т.д. Из удобных и доступных вариантов - промисы.
  • Создать простую админку?

    dhat: ну сколько у вас людей будет в минуту заходить?)
  • Создать простую админку?

    dhat: зависит от предполагаемой нагрузки но думаю хватит.

    Vladislav: второй только вышел. Банально еще не достаточно много чего есть что бы быстро делать дела. Если у вас есть время - то можно юзать второй. Если же взять angular 1.5+ можно делать все то же что и на втором просто проще и чуть меньше возможностей. Но подходы те же можно использовать.
  • Как программировать протоколы сетевого уровня?

    каким образом вообще можно разработать новый протокол


    А зачем вам "новый" протокол? Чем имеющиеся не подходят?
  • Создать простую админку?

    Aset: лучше первый ангуляр. Второй тут не нужен.

    dhat: потому что там есть уже готовая регистрация - а вам же побыстрее надо дела сделать, нет? Ну и бэкэнд не нужно делать - все уже готово.
  • Как лучше разбить логику?

    Владимир:

    для начала крайности:

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

    Мунусы очевидны - никогда не знаешь какая часть кода с каким состоянием работает и какие побочные эффектиы это все вызывает. Приходится сильно париться. Поддерживать код дико сложно.

    Другая крайность - все в объектах. То есть состояние "заперто" внутри объекта и никогда наружу не ходит (никаких геттеров). Состояние дробится на объекты, логика обработки данных так же пихается в те объекты в которых есть нужные данные. Если одна операция нуждается в данных двух объектов - операция делится на части. Если надо взаимодействие с внешним миром - делается объект приоткрывающий внешний мир для объектов чуть-чуть (не dao или там коннекшен к базе а именно отдельная операция маленькая). Так же большая часть объектов имутабельна. То есть если данные поменялись - мы делаем копию объекта с новыми данными (это что б совсем в крайность).

    Плюсы - полный контроль над состоянием и удобства с точки зрения внесения изменений. Минусы - приходится тратить больше времени и думать что делаешь. Ну то есть тупо фигнуть код уже не выйдет - надо разбираться зачем этот код нужен. Для сложной логики - это положительная штука. Но в большинстве задач это оверхэд который окупается только в долгосрочной перспективе или когда изменения приходят очень часто.

    Ну то есть когда мы делаем объект хранящий стэйт и объект хранящий "методы" (процедуры) - мы как бы имеем дело больше с процедурным программированием, нежели с ООП. Просто в этом случае наше состояние хотя бы изолировано и мы можем легко проконтролировать кто с чем работает. Значительную часть минусов процедурного программирования мы таким образом устраняем. И в среднем выходит неплохо. Но при большом количестве изменений менять нужно будет больше за счет чего скорость разработки падает. Есть еще такой термин как "лазанья код", это когда что бы поменять что-то на одном уровне нам надо "прорезать" все слои.

    Что использовать - дело разработчика. мне вообще кажется что компромис - это комбинирование подходов. Тогда сложные вещи можно сделать в ОО стиле а все остальное - в простом процедурном.

    Я использую полностью ОО подход только на личных проектах потому как нужно немного по другому думать для этого. А для коммерческих проектов "заставлять" команду так думать я не хочу. Потому иногда и сеттерами не гнушаюсь, не то что геттерами.
  • Как лучше разбить логику?

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

    не совсем понял почему вы решили что user manager должен менятся.

    Например мы добавляем какое-то поле для юзера. В этом случае нам надо поправить UserDTO, UserManager и UserDao. Я не прав?

    manager - нужен для того чтоб определять бизнеса логику для user.

    У меня раньше были менеджеры - теперь я их дроблю на объекты описывающие юзкейсы. Один юзкейс - один объект. Высокоуровневое описание бизнес логики если хотите. Так лучше с точки зрения SRP.

    Правда я предпочитаю jdbc всяким orm фреймворкам.

    Я SQL использую только для выборок и когда задача в контексте ORM плохо решается (они все же не для всего придуманы а только для маленьких транзакций). Банально скорость разработки увеличивается.

    получится domain object, в котором модель данных будет смешана с бизнесс логикой.


    При использовании средств вроде Hibernate - не будет. Будет только объектная модель.

    При наличии сложной бизнесс логики этот обьект рано или поздно постигнет участь god-class

    Просто надо дробить объекты на поменьше.

    как минимум проблемы с конкурентыми модификациями, постоянные мерджи.

    Эм... немного может не понял о чем вы? Если вы просто про атомарность операций с данными в базе - есть разные варианты вплоть до отказа от изменения состояния (append only структуры). А если мы про GIT - классы всеравно следует делать как-то небольшими. И при отсутствии километров геттеров и прочего мусора - кода выходит на самом неде не так много. Так же всегда можно делигировать какие-то задачи другим объектам.

    Я буду утверждать что ваш подход хуже но мне кажется он имеет место быть только в случае использования ORM фреймвоков у которых нет явно выраженного data access layer или для маленьких проэктов которым плевать на перфоманс.


    согласен. Хотя тут тоже есть нюансы. Например мы можем использовать row data gateway для того что бы хранить там модель данных и иметь возможность прямых операций над оными. Обычно оно работает значительно быстрее чем мэпперы. Хотя современные мэпперы (во всяком случае те которые использую я) и так довольно быстры.

    Но да, на своих проектах "перформанс" у меня на втором плане. Если я сэкономлю 10 часов разработки этого мне уже хватит что бы пол года оплачивать лишний сервак. Есть проекты где требования такие что... это уже не прокатит, для них можно пойти на компромис.
  • Какие есть PHP Refactoring Tools или Ваши идеи по доработке существующих или созданию?

    PO6OT: ну так в вашем примере вы худо бедно читабельный код превратили в нечитабельное мессиво. Это обфускация. А рефакторинг - это когда мы берем код и делаем его лучше.
  • Как лучше разбить логику?

    Владимир:

    речь идет о enterprise приложении то классы должны попадать в одну из категорий: model, controller


    А как же инфраструктура? А модель как же? Это не один объект - это множество объектов формирующих возможно даже не один слой. Рекомендую вам ознакомиться с книгами Эрика Эванса и Крэйга Лармана что-бы осознать что в кровавом "энтерпрзайзе" не все так просто.

    Их роли такие же как и в паттерне MVC, модель хранит данные а контроллер управляет состоянием модели.


    Популярное заблуждение и подмена понятий.

    Для начала давайте определимся что есть ООП и что есть процедурное программирование.

    Процедурное программирование - это когда у нас есть данные и есть процедуры. То есть когда мы геттером из одного объекта достаем данные что бы что-то с ними сделать - это процедурное программирование с классами. То есть глобального состояния уже нет и жить нам проще но это еще не ооп. Инкапсуляция нарушена.

    ООП - это когда состояние и поведение находятся в одном объекте. То есть если у вас есть код и этому коду нужны какие-то данные - значит это дело должно находиться в одном и том же объекте. Между объектами могут ходить только сообщения, а не данные. Тип "сделай это, сделай то". А объект уже сам разберется как что сделать - все данные у него и так есть (паттерн информационный эксперт).

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

    А анемичные модели - то есть тупо модель данных - это антипаттерн. Но если мы говорим в контексте процедурного программирования - то все хорошо.

    вернемся к MVC. Для начала вспомним проблему, которую MVC должен был решить в бородатом 79-ом году. В то время появился графический интерфейс, и приложение должно было уметь работать как в консоли например, так и в графическом режиме. Более того, графический интерфейс менялся чаще чем логика, а потому излишняя связанность между UI и логикой вредили делу и усложняли введение изменений (шаблон smart ui).

    Так же напомню что в бородатом 79-ом году отрисовать UI - это не сформировать xml-ку. Это работа с объектами. То есть у нас был один объект, который на вход принимал данные и формировал view. Это собственно и был View-объект, который подписывался на изменения в объекте Model (который внутри мог иметь другие объекты и являлся лишь вершиной графа) и занимался формированием представления. Активная вьюшка (потому что она делает дела а не кто-то другой).

    Затем контроллер. Задача контроллера - словить событие от вьюшки (в оригинальной публикации 79-ого года упоминаются так же редакторы - контролы на вьюшке генерирующие события), которые описывают действия пользователя с оной, и преобразовать это асинхронное действие пользователя в синхронное сообщение к модели. То есть контроллер никогда и ни при каких обстоятельствах сам с моделью ничего не делает. Он просто просит модель что-то сделать а та уже сама решает делать или нет. Сама сгенерирует событие для вьюшки и вьюшка сама себя обновит.

    Это потом с течением времени активная вьюшка оказалась неудобной и ее заменили на пассивную. А между вьюшкой и моделью поставили медиатор - презентер. И называли это MVP. На бэкэнде последние лет 20 больше применяют вариации похожие больше на MVA (Model-Adapter-View, я переставил что бы взаимоотношения были правильными). Возможно вы так-же слышали фразу про "тонкие контроллеры" и сервисный слой.

    И соль тут в том что M в этом плане - это точка соприкосновения вашего приложения и UI. Не более. То есть внутри - все что угодно. MVC это только про UI.

    Поэтому класса User который хранит данные и имеет набор операций для манипуляции над ними - быть не должно (single responsibility)


    SRP штука хорошая, но вы видимо не так ее трактуете. Я трактую SRP как Single Reason to Сhange (и так ее трактует популяризатор SOLID - дядя боб). То есть если вам надо менять userManager просто потому что поменялся UserData (или UserDAo или UserDTO - как хотите) - то явно что-то пошло не так и мы как-то не правильно разделили все на объекты. Мы можем выделить объекты, которые нам необходимы для создяния юзера (UserBuilder например, типичная фабрика). Как минимум потому что нам надо совершить какую-то операцию над тем, чего у нас еще нет. Убираем UserDTO, убираем UserManager, убираем UserData и получаем User.

    Словом... мне больше нравится подход при котором у нас знания элементов системе друг о друге ограничены просьбами что-то делать и данные между элементами системы не ходят.

    в мире java такое уже давно не актуально... как в других языках обстояит дела я не в курсе


    Например если взять data mapper и hibernate. Вы же не будете писать там геттеры с сетерами для сущностей? В чем тогда смысл хибернейт использовать? table gateway нам за глаза в большинстве случаев хватит.

    Или вы какие-то еще подходы используете?
  • Как лучше разбить логику?

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

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

    Alexej Simakov: можно делать дела не давай доступ к состоянию объектов вообще. Вот совсем. Собственно это и подразумевается под инкапсуляцией. А когда вы даете доступ к состоянию - то с точки зрения инкапсуляции все... ну чуть лучше чем в варианте с публичными свойствами.