Опять я путаюсь с регулярками(

[Духовность™]

Парни и чем это плохо?

непрозрачностью. Как будет называться метод с джойнами? Как будет называться метод с вложенным select-ом? Твоя попытка написать такие магические методы - это попытка реализации SQL на PHP.

Я магические методы использую для сущьностей(моделей), когда $user->getFirstName() возвращает свойство $this->first_name объекта. Это в любом случае прозрачно, всегда, а преимущества неоспоримые - можно создать явный метод со своей исключительной логикой.

Если тебе хочется какой-то унификации, используй базовый класс с основополагающими методами:

findById($id)
findList() // или findAll()
findByParams($params)
save($object)
delete($object)

а в конкретных классах создавай методы расширяющие базовый класс. Например, такие:

function getUsernameById($id)
{
   $params = array(/* тут  формируем параметры для метода findByParams*/);

   return parent::findByParams($params)
}

 

[craz]

ну как бы не совсем, то что ты говоришь, у меня данная модель расширяет Zend_Db_Table - а там и так много чего доступно типа
findById($id)
findList() // или findAll()
findByParams($params)
save($object)
delete($object)

данный класс призван унифицировать работу не со всем сиквелом в проекте, а только с одной таблицей, ну или такой подход будет применяться во всех моделях таблиц, но в моделях таблиц он будет описан, а не модель конкретной таблицы будет расширять класс с этой магией.

Как такой подход?

И кстати при использовании phpDoc - в чем не явность?

 

[craz]

а в конкретных классах создавай методы расширяющие базовый класс. Например, такие:

function getUsernameById($id)
{
   $params = array(/* тут  формируем параметры для метода findByParams*/);

   return parent::findByParams($params)
}

а вот это уже мягче, ну так и вопрос чем это в плане явности отличается от магии? Я правда не понимаю, я не спорю мне понять просто.

 

[Духовность™]

чем это в плане явности отличается от магии?

Тем, что магия рано или поздно даст сбой. Регулярное выражение get(\w+)By(\w+) -- оно ограничено в своей сущьности. В чем смысл "занимать" __call кодом, который сработает лишь на get "что-то" "откуда". А как же LIMIT? А ORDER? А другие операторы SELECT-a? Тебе напомнить, сколько всего может быть в mySQL?

SELECT [STRAIGHT_JOIN]
       [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
       [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS] [HIGH_PRIORITY]
       [DISTINCT | DISTINCTROW | ALL]
    select_expression,...
    [INTO {OUTFILE | DUMPFILE} 'file_name' export_options]
    [FROM table_references
      [WHERE where_definition]
      [GROUP BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [HAVING where_definition]
      [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [LIMIT [offset,] rows | rows OFFSET offset]
      [PROCEDURE procedure_name(argument_list)]
      [FOR UPDATE | LOCK IN SHARE MODE]]

Твоя магия сможет обеспечить поддержку всего этого? Нативный SQL, зашитый в методы - сможет. И билдер запросов сможет. А твой код - нет. Поэтому и не гибко.

 

[craz]

Тем, что магия рано или поздно даст сбой. Регулярное выражение get(\w+)By(\w+) -- оно ограничено в своей сущьности. В чем смысл "занимать" __call кодом, который сработает лишь на get "что-то" "откуда". А как же LIMIT? А ORDER? А другие операторы SELECT-a? Тебе напомнить, сколько всего может быть в mySQL?

SELECT [STRAIGHT_JOIN]
       [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
       [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS] [HIGH_PRIORITY]
       [DISTINCT | DISTINCTROW | ALL]
    select_expression,...
    [INTO {OUTFILE | DUMPFILE} 'file_name' export_options]
    [FROM table_references
      [WHERE where_definition]
      [GROUP BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [HAVING where_definition]
      [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC], ...]
      [LIMIT [offset,] rows | rows OFFSET offset]
      [PROCEDURE procedure_name(argument_list)]
      [FOR UPDATE | LOCK IN SHARE MODE]]

Твоя магия сможет обеспечить поддержку всего этого? Нативный SQL, зашитый в методы - сможет. И билдер запросов сможет. А твой код - нет. Поэтому и не гибко.

ну постой, я ж и говорю не про

class MYSQLSuperPuperClass
от которого наследуется все приложение и вся работа с базой, я говорю о маленьком расширении конкретного класса. с коллом отдельных задокументированных обращений, в случае если нужно будет расширять то колл просто преписываеться - расширяясь в функцию конкретную

 

[Духовность™]

Ты моё мнение услышал. Решать тебе. Я априори не сторонник оправдывать кривое, на мой взгляд, решение "маленьким расширением". Я достаточно поел какашек, когда программировал по принципу "если нельзя, но очень хочется, то можно". Уже несколько месяцев рефакторингом занимаюсь и конца ему не видно.

 

[craz]

Ты моё мнение услышал. Решать тебе. Я априори не сторонник оправдывать кривое, на мой взгляд, решение "маленьким расширением". Я достаточно поел какашек, когда программировал по принципу "если нельзя, но очень хочется, то можно". Уже несколько месяцев рефакторингом занимаюсь и конца ему не видно.

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

 

[MiksIr]

Суть в том, что оно тебе не нужно. Т.е. это исключительно украшательство, которое даже читабельности кода не добавит. А путаницу внести может.
По сравнению с банальным findByParams.
Обычно такое не делают, потому что просто время на это тратить придется, а отдачи - никакой.

 

[movRAX]

Какая-то демоническая магия ваще-то пошла уже
/^select(\w+)by(\w+)$/

$name = str_replace('select', '', $name);
explode('By', $name);

Чем плохо?