DevMan

Знамо дело - угрозы, паяльник...
В википедию заглянуть не судьба?

Не смог удержаться, простите.

Мартин Фаулер круто пишет обо всех паттернах. Про DI можно почитать тут. Вообще у него отличный блог. И он же автор книги P of EAA. Правда русский ее перевод крайне не рекомендую читать, можно только запутаться, так что читайте в оригинале.

Если хотите разобраться с паттернами, то самая простая (и при этом дельная!) книга - это Фриман&Фриман. Ее можно читать и на русском.

Применительно к PHP - вот лучшая книга про шаблоны (и не только), которую я видел PHP. Объекты, шаблоны и методики программирования от Мэт Зандстра.

Порядок прочтения рекомендую следующий: Фриман&Фриман, затем Мэт Зандстра, и на десерт Фаулера P of EAA.

UPD:
Важно отличать паттерн Dependency Injection от Dependency Injection Container.
Простейший пример внедрения зависимости:

interface IEngine {}
 
class V8Engine implements IEngine {}
 
class Car {
  public function __constructor(IEngine $engine) {
    $this->engine = $engine;
  }
}
 
$car = new Car(new V8Engine());

Простейший пример игнорирования явного внедрения (для такого кода трудно писать unit-тесты, его труднее понимать и править):

class V8Engine {}

class Car {
  public function __constructor() {
    $this->engine = new V8Engine();
  }
}

$car = new Car();

Отличный (и легковесный) пример DIC - это pimple:

// define some services
$container['session_storage'] = function ($c) {
    return new SessionStorage('SESSION_ID');
};

$container['session'] = function ($c) {
    return new Session($c['session_storage']);
};

Советую прочитать и понять его исходники, чтобы убедиться, что в DIC (во всяком случае для PHP) нет никакой магии. Первая версия была всего ~100 строк. Необходимо также отметить, что класс Session использует шаблон Dependency Injection, явно определяя свою зависимость от SessionStorage. А контейнер делает лишь правильную связку.

И да, контейнер сам по себе можно использовать как service locator, если к нему, например, есть глобальный доступ. Но это очень плохая практика, потому что если что-то обращается к сервис локатору, то формально оно начинает зависеть сразу от всех компонентов системы.

Привет.
https://github.com/mgenev/nodember ? На discuss.emberjs.com время от времени появляются вопросы какой backend для Ember лучше. Чаще всего фавориты ROR || Sinatra, Django Rest Framework, Sails.js.

PHP никто не упоминал, но думаю Laravel 4-5 хорошо подойдут. Symfony 2 точно нет.

Все дело в том что ember-data организовывает REST API по принципам описанным в jsonapi.org и вроде как нет смысла эти принципы переопределять, там все довольно продумано и гармонично. На сайте есть раздел со списком библиотек поддерживающих jsonapi.

Мои ИМХО что будущее крупных веб-приложений все же за websokets, а не за http, поэтому я потихоньку посматриваю в сторону GO, но про него сказать ничего не могу.

Update: 07.03.2015

Нашел sanestack.com, Ember.js + Sails.js

Серьезно. Вот Вы потратили 5, 10, 20, 100 часов что б реализовать вот это. Потом - время на написание вопроса. В конце еще написали

Собственно вопрос: есть ли красивый выход из ситуации?

То есть, в такой формулировке, вы предполагаете, что возможен вариант, что красивого выхода не существует (хотя, мне и сложно представить, каким бы был мир в таком случае)... И Вы даже не решили сначала, как это любят говорить менеджеры в наше время, проинвестигейтить этот вопрос? Действительно, Вам кажется, что может быть вариант, что, например, Ebay - имеет у себя пару петабайт регулярных выражений?

Я просто оставлю это здесь:
en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%...
zlob.in/2013/03/fasetnaya-poisk-v-internet-magazine

На самом деле это интересный вопрос. А, точнее, два: зачем нужен такой класс, и зачем их пишут.
Ответ на первый становится очевиден, когда начинаешь не смотреть на код, а писать его ;)
Практически все библиотеки, представленные в РНР, представляют в пользование программиста довольно низкоуровневые функции, которые позволяют, с одной стороны, довольно гибко управлять процессом, но с другой - делают этот процесс ну очень многословным. Самый яркий пример - CURL. Никто, находясь в здравом уме, не будет писать все время эти бесконечные curlopt. Надо пилить библиотеку, которая реализует стандартные методы пост, гет за один вызов, и только для исключительных случаев позволяет задать кастомные параметры.

То же самое касается и работы с БД. К примеру, очень часто нам бывает нужно получить из БД массив. Сколько строк нужно написать для этого? Классическим говнокодом - 5:

$ret = array();
$res = mysql_query();
while ($row = mysql_fetch_assoc($res)) {
    $ret[] = $row;
}

И такой код надо написать раз 15-20 за приложение. У программиста сразу руки зачешутся уничтожить этот повторяющийся код и написать функцию, которой передаешь запрос, а получаешь массив. За 1 вызов. Вот для этого библиотеки и пишут.

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

Возьмем для примера код примера из мануала. Даже выкинув из него очевидные глупости, мы получаем пол-дюжины строк кода. Это на ОДИН запрос.

if ($stmt = $mysqli->prepare("SELECT District FROM City WHERE Name=?")) {
    $stmt->bind_param("s", $city);
    $stmt->execute();
    $stmt->bind_result($district);
    $stmt->fetch();
}

И это все - чтобы получить единственную строчку!

В то время как с помощью (нормальной) библиотеки вся работа с БД сведется к 1 (одной) строчке, а все необходимые телодвижения будут выполнены библиотекой автоматически:

$distr = $db->getOne("SELECT District FROM City WHERE Name=?", $city);

Теперь перейдем ко второму вопрос - зачем их пишут.
Самый основной мотив - "шоб було!" "У всех есть - значит, и у меня будет!". При этом, подходя к написанию библиотеки, новички наступают на одни и те же грабли.
Чаще всего, из-за недостатка опыта авторов, код сокращается только для самых примитивных запросов. Но при этом работа с нестандартными запросами превращается в ад. Но самое ужасное - практически никогда такие самописные библиотеки не поддерживают работу с подготовленными выражениями. А это должно быть их главной фичей, без которых ценность сразу стремится к нулю. А точнее, даже к минусу, потому что инъекции. Ну и по мелочи: к примеру, если в коде действительно написано $db->FetchArray(); - то это ужас, летящий на крыльях ночи, потраченной на отлов неочевидных ошибок .