Сергей Протько

только если вы дизайнер и верстка это не то чем вы будете заниматься.

У вас может быть и модель, и прдставление и контроллер хоть в одном файле, суть то не в этом.

MVC описывает не все приложение (есть Model2 которое убого но описывает все приложение, но я бы не рекомендовал вам сейчас на него ориентироваться). Оно описывает только "как сделать так, что бы приложение ничего не знало о UI".

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

Далее, у нас есть представление. Вопреки вашему мнению, представление это не html а http. Поскольку PHP должен сформировать именно HTTP ответ (так или иначе, при помощи echo и header или при помощи абстракций над http). Просто обычно сайтики в качестве тела ответа содержат html. Но намного проще воспринимать "представление" как HTTP ответ. "шаблонизаторы" в этом плане не относятся к представлению, это способ его генерации. Сделаем допущение что весь view в нашем MVC это обычный HTTP ответ. Просто кусок текстовой инфы выплюнутый в буфер вывода. Помимо HTTP есть еще варианты: CLI или консольные скрипты, у них сфой формат представления. А еще есть менеджеры очередей и кучи других вариантов.

Так же есть еще HTTP запросы, которые по сути являются частью представления, а точнее может восприниматься как какое-то действие пользователя. Причем под пользователем я подразумеваю не обязательно живого человека, а все что угодно, что может отправлять запросы. Браузеры, боты, краулеры, ваше же приложение.

Ранее мы уже сказали что "шаблонизаторы" это не часть представления а только способ его получения. Где мы должны использовать шаблонизатор тогда? Как сделать так, что бы наша "модель" или точнее наше приложение ничего не знало об этом "шаблонизаторе" (или сериалайзере, или json_encode, или еще чем-то там)? Положим между представлением и моделью что-то промежуточное - контроллер.

Опять же контроллер - это не обязательно один объект. Это может быть целая цепочка объектов, которая может передавать запросы друг дружке и что-то с ними делать. Например один "контроллер" глянет мол "ага, он в качестве тела запроса прислал json - десериализуем". А второй контроллер такой "ага, он должен быть авторизован - надо проверить". Ну и т.д. покуда мы не дойдем до последнего контроллера в цепочке, который уже будет дергать "один" метод модельки. Это слой адаптеров между http и нашим приложением. Вот ключевая мысль MVC на бэкэнде (или ели точнее Mediating controller MVC или MVA, паттерн который реализован в большинстве современных бэкэнд фреймворков).

Зачем нужно отделять UI от приложения? потому что что-то из этого явно меняться будет чаще и не одинаково. А еще можно распаралелить работу. А еще можно заменить реализацию одной из частей без вреда для другой. Словом мы получаем намного больше гибкости, но только если приложение ничего не знает о представлении.. В противном случае мы получаем антипаттерн под названием smart ui, для борьбы с которым 40 лет назад и придумывали MVC.

Можно их как-то объединить?

Вы можете указать у двух правил маршрутизации один экшен контроллера. Но не "объеденять правила". В целом не рекомендую "объеденять" эти штуки. С дублированием по другому борятся.

По следующей проблеме - trailing slashes. читаем доку.

symfony.com/doc/current/best_practices/index.html

Использую mvc модель

почитайте еще раз что это такое и зачем оно надо.

Я хочу подгружать текст статьи через ajax,

Ajax, он же XmlHTTPRequest - это просто API для выполнения HTTP запросов из javascript. С точки зрения бэкэнда (то есть php) - это просто очередной http запрос. То есть никакой разницы.

Сначала разбираемся что такое "итератор", потом открываем доку, там в комментариях даже приводят ваш случай в качесве варианта использования. Ну и потом вообще разные виды итераторов смотрим.

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

пароли генерируются, помещаются в inventory или host_vars и хранятся в зашифрованном виде (например при помощи ansible vault). Генерить их при провиженинге машины не очень хорошая идея, хотя иногда удобно.

для начала определитесь с определением "прочитанное сообщение". Когда оно должно считаться прочитанным. А там далее уже делайте.

p.s. не unreadCount а countUnread, так оно как-то приятнее звучит.

учить регулярки.

Время рефакторинга!

$scope._url = "";
$scope._login = "";
$scope._password = "";

Вы же знаете что есть controllerAs который рекомендуется использовать согласно angular styleguide и всем остальным существующим бест практис? (объяснение чем черевато не использовать оное читать в том же angular-styleguide).

$scope.sortFunc = function (a, b) {
    if (a.id> b.id) {
      return 1;
    }
    if (a.id< b.id) {
      return -1;
    }
    return 0;
  };

Вы же знаете что в ангуляре есть встроенный фильтр orderBy?

function AppCtrl(orderByFilter) {
    this.foo = orderByFilter(collection, 'id');
}

var inc = 1;

if(tempArr.length > 0){
var lastItem = tempArr.last();
inc = lastItem.id+1;
}

вы же знаете что это не гарантирует уникальность, и может вызывать проблемы? Для таких вещей удобнее использовать какую-либо реализацию UUID (CUID например: https://github.com/ericelliott/cuid)

Ну и да - ватчер вам тут не нужен так как вы точно знаете когда у вас что произошло. И бейте себя по рукам каждый раз как ставите у ватчера true третьим аргументом.

1) изолировать код в песочнице, передавать в качестве аргументов только то что можно юзать (php.net/manual/en/function.create-function.php)
2) воспользоваться, например, nick/php-parser и удостовериться что не используются штуки типа global

нубство. Выносите общее в методы, в общие зависимости. Почитайте про DRY.

Дублирование позволительно если это... ну тупой код и от дублирования никуда не деться. Но у вас тут какие-то выражения, логика, поведение дублируется. А это уже нубство.