И ещё не совсем понятно, зачем вы здесь ввели в целом 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 будет автоматом в таком режиме (от этого правда больше негатива, чем позитива).
Я считаю правильнеым завязывать бизнес логику на модели и контроллеры, да. ORM просто предоставляет средства. О нём в идеальном случае я и знать-то не должен, как это проиходит в случае с Java Persistence Objects.
Я уже написал об основных:
1. Явно ненужное Dependency Injection ввиде DataBase_Object
2. Создание DataBase_Getter'а каждый раз, когда идёт обращение к DataBase_Db::getGetter(), что конечно же очень «оптимально» для памяти.
3. Отсутствие адаптера для подключения.
4. Отсутствие программной поддержки блокировок ( см. «Пессимистическая блокировка», «Оптимистическая блокировка»), т.е. оно есть но я никак не смогу узнать заблокирована ли таблица в настоящий момент, и т.д.
То есть, Composite ведь должен неявно реализовывать логику множественного. Либо, вы могли бы в целом отказаться от ICompositeStrategy и ввести стратегию композиции — StrategyList(...).
Я бы на вашем месте ещё и в стороны шаблона Builder посмотрел.
Composite + Strategy — немного уводят от основного смысла, хотя нельзя сказать, что ваши
сущности ими не являются.
Eclispe и Idea умеют запускать MVN-задачи, а редеплоится Jetty будет автоматом в таком режиме (от этого правда больше негатива, чем позитива).
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 ) ] ];
}
$db->user->…
$db->user_gold->…
Мне, допустим, нужно чтобы user и user_gold — были одной и той же таблицой.
2. Зачем это допускать, если этого можно избежать? См. Фабрика объектов.
P.S Ещё подумайте в сторону наследования.
1. Явно ненужное Dependency Injection ввиде DataBase_Object
2. Создание DataBase_Getter'а каждый раз, когда идёт обращение к DataBase_Db::getGetter(), что конечно же очень «оптимально» для памяти.
3. Отсутствие адаптера для подключения.
4. Отсутствие программной поддержки блокировок ( см. «Пессимистическая блокировка», «Оптимистическая блокировка»), т.е. оно есть но я никак не смогу узнать заблокирована ли таблица в настоящий момент, и т.д.