#php #symfony1 #propel
#php #symfony1 #продвигать
Вопрос:
У меня такой сценарий:
- Веб-сайт для управления отелями.
- В ходе проекта был добавлен другой вид модели отеля, так что теперь их два.
- Теперь босс хочет, чтобы список отелей включал оба типа отелей.
Я думал о следующих возможных решениях:
- Создайте суперкласс, содержащий общие свойства, необходимые для отображения в списке отелей, и переопределите соответствующим образом.
- Взломать мой способ в представлении. Теперь у него один цикл, по ходу которого создается HTML-код (очевидно). Если это сработает, будет два цикла.
Проблема, которую я вижу в подходе № 1, заключается в следующем: «Hotel1 расширяет базовый hotel1», «Hotel2 расширяет базовый hotel2». Итак, хорошо, я создам суперкласс, что тогда?
Проблема с подходом № 2 заключается в следующем: я все еще далек от «профессионального» разработчика Symfony, и я не уверен, что рассматриваемое представление вообще будет иметь доступ к нескольким методам модели. Может быть, будут работать рендеринговые части из другого модуля?
Итак, как мне это сделать? Как вы думаете, проблемы, которые я перечислил, легко решить? Видите ли вы другие подходы?
Если да, пожалуйста, поделитесь своими мыслями. Спасибо!
Комментарии:
1. Насколько похожи две модели отелей? Содержат ли они много перекрывающихся полей?
2. Они делают. У них 8 похожих свойств — просто с разными именами столбцов в БД. Вторая модель отеля имеет еще несколько свойств, но они, к счастью, не имеют отношения к действию по составлению списка отелей. На данный момент у меня есть полный контроль над проектом, и я, вероятно, смогу объединить таблицы / модели. Однако любопытно узнать о других альтернативах.
Ответ №1:
Я знаю, что вы отметили свой вопрос тегом Propel , но я бы рассмотрел возможность использования здесь наследования Doctrine — если есть эквивалент Propel — либо ‘concrete’, либо ‘column aggregation’ (в зависимости от того, как вы хотите хранить свои данные). По сути, в итоге вы получите базовый Hotel класс, от которого затем будут расширяться eg Hotel1 и Hotel2 классы.
Таким образом, вы можете иметь методы, общие для обеих моделей в классах Hotel model и table, а затем методы, специфичные для отеля, в классах Hotel1 и Hotel2 .
Редактировать: Только что нашел эквивалент Propel, хотя эта ссылка предназначена для Propel 1.5. Однако, похоже, что Propel 1.3 поддерживает только «простой» тип наследования.
Комментарии:
1. Похоже, мне нужно объединить две таблицы БД.
2. Да, это правильно. Делая это, вы все еще можете сохранить расширенные поля для
Hotel2, но также иметь методы, которые работают в обоих классах, а также возможность легко отображать все отели в одном списке (и впоследствии фильтровать поHotel1илиHotel2и т.д.).3. Итак, давайте будем точны: я создаю SQL-скрипт для создания одной таблицы большего размера (или заставляю Propel генерировать ее для меня), я выполняю шаги, указанные по этому URL, затем я разрабатываю 2 скрипта для переноса данных из исходных 2 таблиц в новую таблицу, затем запускаю его, и это работает? 😉
4. Предполагая, что ваши пальцы тоже скрещены, это звучит надежно 😉 хех, я бы выбрал Propel, создающий таблицу первым — таким образом, у вас есть связанный PHP для работы с ней, а также определенные имена столбцов для работы. Но да, так и должно быть … 🙂
5. Если вы собираетесь объединить оба набора данных, то вы могли бы отказаться от наследования и просто использовать поля Hotel2 в качестве необязательных элементов для записей Hotel1. И в итоге вы получите таблицу ‘Hotel’, возможно, с флагом индикатора. Возможно, наследование здесь просто слишком усложняет ситуацию 🙂
Ответ №2:
Doctrine предоставляет хорошее решение здесь. Взгляните на наследование агрегирования столбцов. Возможно, Propel предоставляет что-то подобное, но я не знаком с propel…