nikelin
0
У нашей компании ( a5000.ru ) был подобный опыт.
nikelin
–1
Жаль, что не хватает кармы, чтобы поставить плюс.
nikelin
+1
Но зачем Кристоферу Стэнглу понадобились эти данные в формате CSV-файла на рабочем столе его ноутбука?..
nikelin
0
Да, возможность скриптинга и Data-Driven Design — это прикольно.
nikelin
0
И ещё не совсем понятно, зачем вы здесь ввели в целом ICompositeStrategy не унаследовав IStrategy при этом.
То есть, Composite ведь должен неявно реализовывать логику множественного. Либо, вы могли бы в целом отказаться от ICompositeStrategy и ввести стратегию композиции — StrategyList(...).

Я бы на вашем месте ещё и в стороны шаблона Builder посмотрел.
nikelin
+1
У вас просто получился объектный Expression Language. Если бы вы немного выше абстрагировались бы, то у вас бы логика процессинга перенеслась бы из perform() в некоторый Interpreter или в коллекцию Visitor'ов, которые бы проходили вашу иерархию как AST.
Composite + Strategy — немного уводят от основного смысла, хотя нельзя сказать, что ваши
сущности ими не являются.
nikelin
+1
Дык, тут особых Hibernate-специфичных моментов и нет, а те что есть отвечают только за листинг базы. Используйте вместо Hibernate Criteria — Criteria API из JPA 2.0.
nikelin
0
Никак. Тут тоже самое, что и с фикстурами. Напишите — миграции — всё будет отлично.
nikelin
0
Если в проекте используется Maven, то все проблемы решаются Embeded Jetty плагином.
Eclispe и Idea умеют запускать MVN-задачи, а редеплоится Jetty будет автоматом в таком режиме (от этого правда больше негатива, чем позитива).
nikelin
–1
Господи, да статья же мусорная. Как её можно плюсовать?
nikelin
+1
Orangina'у готовит ;-)
nikelin
–6
Это тип сайт appdata.ru беспалевно траффик генерит, насылая школьников или пенсионеров писать статьи на хабрик?
nikelin
+1
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 ) ] ];
}

nikelin
0
Аспектно-ориэнтированный полиморфизм… замечательная идея!
nikelin
0
Я считаю правильнеым завязывать бизнес логику на модели и контроллеры, да. ORM просто предоставляет средства. О нём в идеальном случае я и знать-то не должен, как это проиходит в случае с Java Persistence Objects.
nikelin
0
Наследования модели A от модели B.

$db->user->…

$db->user_gold->…

Мне, допустим, нужно чтобы user и user_gold — были одной и той же таблицой.
nikelin
0
1. Это очень плохо, потому что это не нужно, ибо сам объект User нигде явно не используется.

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

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

Вы лучше посмотрите как это реализовано в концептуально плане в Hibernate и в iBatis (в ней как раз всё очень хорошо с кастомными запросами и user defined связывателями полей таблицы с классом ). Пусть они и на Java, но это не важно для понимания основополагающих принципов.
nikelin
0
1. Расширять её в текущей версии не позволяют ошибки проектирования, т. к. даже подключение к базе не абстрагировано.

2. Сразу скажу, использовать её я не буду :-)
nikelin
0
Обычно тормоза не из-за ORM, а из-за ошибок проектирования во время разработки включая отсутствие нормального подхода к кешированию. Даже если дело действительно в ORM, что тоже бывает часто, особенно в случае с Doctrine, вам ничто не мешает переписать особенно тяжеловесные запросы с каскадом JOIN'ов на PDO.
nikelin
0
Плюс, в PDO относительно легко можно перейти на другую БД, там хотя бы есть возможность этого (изменяя значения драйвера поддерживающего текущее подключение), у вас же mysql строго защита в объект Database_Db, что по сути своей ужасно.
nikelin
+1
1. Да, это действительно причина, для создания форка.
2. Нет: forge.mysql.com/wiki/PHP_PDO_MYSQLND
nikelin
+1
PDO встроенный, в таком случае, вам чем не угодил?)
nikelin
0
Не в ту ветку написал
nikelin
0
И если у вас уже так всё лихо закручено с геттерами, которые сопоставляют объект таблице, зачем в таком случае вводит зависимость объектов от DataBase_Object?

Database_Object вполне себе может включать в себя экземпляр связуемого класса, и связывать его поля с полями таблицы через Reflection.
nikelin
0
И если у вас уже так всё лихо закручено с геттерами, которые сопоставляют объект таблице, зачем в таком случае вводит зависимость объектов от DataBase_Object?

Database_Object вполне себе может включать в себя экземпляр связуемого класса, и связывать его поля с полями таблицы через Reflection.
nikelin
+5
ORM по определению должна абстрагировать бизнес-логику от SQL. Тут этого не наблюдается.

Да и вообще… это сложно назвать ORM'ом.
nikelin
+3
Нужно было пост назвать: «Как сделать пространства-имён в PHP5.3 ещё большим говном, чем они есть»
nikelin
–1
Нафига козе баян, если есть MVC?