Сам по себе ORM — банальная ничем не примечательная хрень. Это уже много раз делали в других фреймворках (например, RoR, Java) и описано в книгах про паттерны. Берешь, делаешь как в Руби и пользуешься хоть до посинения.
Пример с User::create() неудачный: у реальных объектов бывает по 20 свойств и фукнция с 20 аргументами будет выглядеть дико. Функции с подчеркиванием в начале — уродливые. Передавать __CLASS__ и подобные магические методы тоже не очень как-то.
Один из сложных моментов в проектировании ORM — оптимальная организация взаимодействия с хранилищем. Например, этот ваш пример:
> foreach(UsersGroup::getPremiumMembers()->orderBy('registration_date')->limit(10) as $user){
> echo $user->getCountry()->getCurrency()->getCode()."
";
Сколько запросов сгенерирует при использовании SQL-хранилища? По идее, должно быть в районе 3-4, причем данные справочников еще бы и стоило кешировать (ибо валюты у стран меняются очень редко) и обойтись 1-2 запросами. Если у вас в цикле для каждого юзера делается запрос — хлам это, а не ORM.
Второй момент — оверхед. Вы когда-нибудь считали, какая разница по времени выполнения запроса через ваш ORM и через mysqli_query() (включая время на загрузку и инициализацию классов ORM)? Посчитайте, наверняка у вас после этого вообще пропадет желание использовать ORMы.
Третий момент — масштабирование. Можно ли, к примеру, сделав огромный сайт на вашем ORM, не переписывая кода, реализовать расшардивание базы на 100 серверов (чтобы справиться с нагрузкой). Можно ли на нем делать проекты уровня хотя бы игр для соцсетей или вконтакта?
Если у вас есть решение хотя бы некоторых из описанных 3 проблем проектирования ORM, ваша статья на тему архитектурных решений и программистских хитростей была бы крайне интересна. Если нет решения — то такой орм любой школьник может сделать, как я уже сказал, прочтя мануал к рубионрейлс.
