Zend с существующим Propel ORM - PullRequest
Новая
       50

Zend с существующим Propel ORM

3 голосов
/ 22 марта 2011

Я работаю над преобразованием довольно большого (но несколько простого) приложения из Symfony в Zend, большого из-за БД.Это также мой первый проект Zend, но пока он идет хорошо.Приложение простое, база данных довольно сложная (я предвижу многочасовое отображение данных вперед, если это будет сделано вручную).

У меня есть весь исходный код, созданный с помощью Symfony FW.Оригинал использует Propel и работает (и имеет более 200 моделей, отображающих БД, 272 на быстрый взгляд).

Мои таблицы БД имеют зависимую строку за строкой, я также повторно использую исходную структуру БД ... прямой импорттаблиц / схем, так что я представляю, что исходный propel по-прежнему будет работать нормально в этом отношении.

Мой вопрос (ы): будет ли потрачено время на повторное использование раздела propel старогоприложение с моей новой Zend-версией приложения?Должно ли это быть прямое предприятие?

Если бы это могло сработать, это может удалить многие бессонные ночи из моей жизни:)

Ответы [ 3 ]

4 голосов
/ 22 марта 2011

Я думаю, что вы можете повторно использовать разделы Propel старого приложения, так как Propel 1.5 (текущий стабильный) и следующие 1.6 обратно совместимы вплоть до Propel 1.3 (используется Symfony 1.0, если я хорошо помню) и его оригинальных «критериев»"синтаксис.

После этого вы получите выгоду от улучшений Propel 1.5 (среди них - приятный синтаксис" Query "), не теряя существующий код.

См .:

3 голосов
/ 23 марта 2011

Классы моделей могут содержать ссылки на классы Symfony, например sfMixer.Они добавляются дополнительным поведением Propel в дистрибутиве Symfony .Поскольку sfMixer, вероятно, не будет существовать в вашем новом проекте Zend, это может привести к ошибкам.

Тем не менее, должна быть возможность повторно сгенерировать ваши модели с чистой установкой Propel (в Zend или в Symfony).с отключенным дополнительным поведением), а затем скопируйте свои собственные редактируемые пользователем файлы классов поверх пустых сгенерированных.

Если вы используете ту же версию Propel в своем проекте Zend, что и в своем проекте Symfony, этодолжно работать из коробки (если вы не редактировали классы Base, но я полагаю, вы этого не делали).Если вы используете более новую версию Propel в Zend для генерации моделей, могут возникнуть проблемы с совместимостью, если вы получите доступ к protected членам, которые с тех пор изменились.

0 голосов
/ 24 марта 2011

Для блага других, кто может заглянуть сюда, я собираюсь ответить на свой вопрос ...

В итоге я установил последнюю версию Propel (1.5). Ян Фабри (выше) упомянул, что в ранее сгенерированных моделях могут быть остаточные элементы (из проекта SF), и это тоже было моей проблемой. Поэтому я запустил «реверс» в базе данных и сгенерировал новые схемы / модели.

Я, конечно, держу исходные сгенерированные модели под рукой, так как я повторно использую существующую базу данных. Я также запустил сборку phpDoc для предыдущего приложения, включая сгенерированные модели Propel, и это служит отличным инструментом для просмотра того, что было сделано ранее. В качестве «побочного» совета я также запустил phpDoc на своих новых сгенерированных моделях, и теперь у меня есть своего рода «справочный документ» для моего нового «пользовательского db api», сгенерированного из сборки Propel ... действительно круто! Уже есть некоторые проблемы со схемой, такие как отсутствие поддержки типов ENUM ... но в версии 1.6 Propel. Оригинальные модели служат рабочим примером того, как Propel использовался с существующей базой данных. Я предвижу редактирование «вручную» нескольких записей в новой схеме, когда возникнут проблемы.

v1.5 в Propel имеет новый API запросов (на который указывает Frosty Z), который заменяет (или улучшает) критерии и «peer» в моем новом приложении. Исходный код все еще служит хорошей моделью (а не моделью MVC) того, как база данных была интегрирована в логику приложения ранее, но я обнаружил, что новая версия API запроса Propels будет большой помощью.

Я читал, что Propel где-то не поддерживает 'объединения', но я вижу, что эта версия поддерживает, и в Propel есть много других новых и полезных функций. Примечательно то, как новый API обрабатывает отношения. Это все в документации в Propel, и я очень хочу использовать это. База данных довольно большая и сложная для «ручного» интерфейса, поэтому «обратная» функция Propel также была очень удобной.

Запросы, подобные этому: 

                    $Users = UsersQuery::create()
                  ->filterByLastName($LastName)
                  ->find(); // $Users is a PropelCollection object
                 return $Users;

довольно «приятно», как сказал Frosty Z, и экономит много кода по сравнению с использованием Zend_Db или прямого PHP / MySQL, и кажется более простым, чем прежние «критерии», «peer». Этот фрагмент был взят из Propel Docs и решает проблему, которая заставила меня искать решение в другом месте; условная находка показала, что его размер будет расти сравнительно. И я уже вижу, как легко будет фильтровать результаты в соответствии с ACL.

Мой ответ - это объяснение того, почему я не использую оригинальные модели; отсутствие новых методов и боязнь остаточного кода, который может вызвать ошибки или головные боли, и почему я застрял с Propel (помимо того факта, что он кажется действительно хорошим); У меня есть пример работающего ORM. На самом деле, я могу сказать, что оба ответа выше - то, с чем я пошел. Спасибо, ребята!

...