У нашей компании ( a5000.ru ) был подобный опыт.

Но зачем Кристоферу Стэнглу понадобились эти данные в формате CSV-файла на рабочем столе его ноутбука?..

Да, возможность скриптинга и Data-Driven Design — это прикольно.

И ещё не совсем понятно, зачем вы здесь ввели в целом ICompositeStrategy не унаследовав IStrategy при этом.
То есть, Composite ведь должен неявно реализовывать логику множественного. Либо, вы могли бы в целом отказаться от ICompositeStrategy и ввести стратегию композиции — StrategyList(...).

Я бы на вашем месте ещё и в стороны шаблона Builder посмотрел.

У вас просто получился объектный Expression Language. Если бы вы немного выше абстрагировались бы, то у вас бы логика процессинга перенеслась бы из perform() в некоторый Interpreter или в коллекцию Visitor'ов, которые бы проходили вашу иерархию как AST.
Composite + Strategy — немного уводят от основного смысла, хотя нельзя сказать, что ваши
сущности ими не являются.

Дык, тут особых Hibernate-специфичных моментов и нет, а те что есть отвечают только за листинг базы. Используйте вместо Hibernate Criteria — Criteria API из JPA 2.0.

Никак. Тут тоже самое, что и с фикстурами. Напишите — миграции — всё будет отлично.

Если в проекте используется Maven, то все проблемы решаются Embeded Jetty плагином.
Eclispe и Idea умеют запускать MVN-задачи, а редеплоится Jetty будет автоматом в таком режиме (от этого правда больше негатива, чем позитива).

Orangina'у готовит ;-)

function declOfNum( $number, $titles ) {
$cases = array( 2, 0, 1, 1, 1, 2 );
return $titles[ ( $number % 100 > 4 && $number % 100 < 20 ) ? 2 : $cases[ mi
n( $number % 10, 5 ) ] ];
}


Аспектно-ориэнтированный полиморфизм… замечательная идея!

Ага, «Брысь майкрософт с Хабра!» ((:

Фу!

Я считаю правильнеым завязывать бизнес логику на модели и контроллеры, да. ORM просто предоставляет средства. О нём в идеальном случае я и знать-то не должен, как это проиходит в случае с Java Persistence Objects.

Наследования модели A от модели B.

$db->user->…

$db->user_gold->…

Мне, допустим, нужно чтобы user и user_gold — были одной и той же таблицой.

1. Это очень плохо, потому что это не нужно, ибо сам объект User нигде явно не используется.

2. Зачем это допускать, если этого можно избежать? См. Фабрика объектов.

P.S Ещё подумайте в сторону наследования.

Я уже написал об основных:
1. Явно ненужное Dependency Injection ввиде DataBase_Object
2. Создание DataBase_Getter'а каждый раз, когда идёт обращение к DataBase_Db::getGetter(), что конечно же очень «оптимально» для памяти.
3. Отсутствие адаптера для подключения.
4. Отсутствие программной поддержки блокировок ( см. «Пессимистическая блокировка», «Оптимистическая блокировка»), т.е. оно есть но я никак не смогу узнать заблокирована ли таблица в настоящий момент, и т.д.