Nihisil: ну тогда я бы больше о конфигурации системы беспокоился. Скажем в лимит по хэндлерам на процесс (по умолчанию вроде как не больше 1024-ех дисприторов один процесс может держать) ну и т.д. А так разницы особо нет. Ну и да, если вас парит производительность - напишите нагрузочные тесты.
Vitaly Vitaly: если ваши проекты это тупой CRUD, который не будет меняться никогда, то согласен, городить сервисный слой и загоняться по тестам нет смысла. Все от задачи зависит.
Если у вас вся бизнес логика вынесена в жирные модели и всем руководят не контроллеры а сервисный слой, ваш код становится более сопровождаемым, проще покрывать тестами (ну и по TDD проще работать) и вообще жизнь становится чуть меньшей болью. А если у вас все размазано по контроллерам то вносить изменения в систему спустя время становится просто ужасно.
Простота должна быть не в реализации, а в структуре и в возможности через пару месяцев прочитать код и понять что там происходит без ковыряний в духе "блин а что все же значит статус "1" вот тут и какие еще бывают...".
Vitaly Vitaly: false вполне себе хороший тригер что бы отключить фильтрацию по статусу. И да, 0, 1, 2 это тупняк. Company::PENDING или что-то в этом духе намного более выразительнее
entermix: зависит от задачи. Если у сотрудников и работодателей есть различные характеристики - то имеет смысл вынести это дело в отдельные таблицы и связать.
У angular если очень давняя и надоедливая проблема - стэктрэйсы ошибок и исключений. Если оно было выбрашено в ватчере, вы без понятия где именно этот ватчер был навешен. Или где был инициализирован запрос, или где-то в цепочке промисов проблемы.... И искать проблему бывает... проблематично и напрягает.
При разработке все эти проблемы частично или полностью решаются, но из коробки естественно ничего нет. Собственно при такой ситуации делать логирование ошибок на сервер бывает... бессмысленно.... потому что потом у вас будут в логах бесполезные стэк-трэйсы.
С другой стороны, есть библиотека zone.js, которую разработали чуваки из команды ангуляра, и которая будет использоваться как фэлбэк в Angular 2.0 для браузеров не поддерживающих Object.observer (то есть будет тайком запускать $digest циклы в автоматическом режиме, когда будут вызываться функции завязанные на дата биндинг).
Так вот, вообще концепция зон для контроля офигительно прекрасна и идея сама по себе крайне проста. Можно попробовать запилить модуль для angular который оборачивает все основные сервисы в зоны, что бы можно было получать нормальные стэк трэйсы.
Павел Китьян: единственное что, готовых наборов директив под w2UI вы под angular не найдете и их придется писать. И скорее всего изучение еще одного фреймворка просто так вам будет не подуше. А angular придется именно учить, разбираться в философии этого фреймворка и т.д.
Павел Китьян: открою вам тайну, тот MVC который вы использовали на бэкэнде, не совсем MVC. Ну да несуть.
Нет, несли вы возьмете Angular, то все что касается UI это директивы, но не контроллеры. Контроллеры экспортируют данные во view, по сути задают viewmodel.
Павел Китьян: ну вот то и значит, что у вас в таком случае бизнес логика и логика представления смешивается. И если мы говорим о серьезном SPA должны быть и шаблоны и кучи других вещей. Иначе это не серьезное SPA а... ну просто SPA.
Вообще решать вам. Хотите, используйте связки всякие типа backbone + marionette, knokout, react, etc...
Павел Китьян: Knockout - библиотека дающая вам дата биндинг, она не решает других задач (раутинг, модели, взаимодействие с сервером). Backbone напротив, решает проблему раутинга и взаимодействия с сервером, но не дает вам структуры и view. По сути Backbone удобная библиотека для реализации моделей.
Angular же самодостаточен, предоставляет вам все выше перечисленное + структура приложения + возможность делать тестируемые изолированные его части. Ember туда же.
Павел Китьян: я не люблю классический десктопный UI. Посему ничего не могу сказать. Что до angular vs backbone вы же понимаете что выбираете между фреймворком и библиотекой?
