СУХОЙ и подобные запросы - PullRequest
Новая
       12

СУХОЙ и подобные запросы

3 голосов
/ 27 февраля 2009

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

$Mysqli = new mysqli;
if ($Stmt = $Mysqli->prepare("SELECT foo 
                              FROM tblFoo 
                              WHERE something = ?")) {
    $Stmt->bind_param('s', $this->_something);
    $Stmt->execute();
    if (0 != $Stmt->errno)
        throw new Exception("blah, blah, blah");
    $Stmt->bind_result($foo);
    while ($Stmt->fetch()){
        $this->_foos[] = new Foo($foo);
    }
    $Stmt->close();
    } else {
        throw new Exception("blah, blah, blah"););
    }
}

и позже, где-то еще ... 

$Mysqli = new mysqli;
if ($Stmt = $Mysqli->prepare("SELECT bar, baz 
                              FROM tblBar 
                              WHERE somethingElse = ?")) {
    $Stmt->bind_param('s', $this->_somethingElse);
    $Stmt->execute();
    if (0 != $Stmt->errno)
        throw new Exception("blah, blah, blah");
    $Stmt->bind_result($bar, $baz);
    while ($Stmt->fetch()){
        // do something else with $bar and $baz
    }
    $Stmt->close();
    } else {
        throw new Exception("blah, blah, blah"););
    }
}

... а потом еще и еще где-то ... и т.д.

Это настоящее нарушение СУХОГО? Похоже, не имеет смысла писать класс для выполнения запросов такого типа (с параметрами конструктора или параметрами для таблицы, столбца, связанных переменных и т. Д.), А затем повторно использовать его в моем приложении. Но в то же время я не могу избавиться от этого ноющего чувства, которое я повторяю.

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

Мысли

Ответы [ 3 ]

1 голос
/ 27 февраля 2009

Я бы сказал, что это было нарушение. Если взглянуть на ваш код (если я что-то упустил), эти два утверждения идентичны, за исключением строк «foo» и «bar» (повторяется несколько раз) и вашей реальной бизнес-логики.

Как минимум, вы можете извлечь это. Более того, все строки SQL, вероятно, должны быть извлечены. Они всегда казались мне скорее данными, чем кодом. Если бы у вас был массив строк SQL, таблиц и т. Д., Это сделало бы рефакторинг более очевидным?

(Извлечение строк и других данных из вашего кода - отличный способ начать рефакторинг)

Одна возможность, если у вас есть объект с именем таблицы и метод, содержащий вашу бизнес-логику, вы можете передать его в «Процессор» со всем образцом (который является всем остальным кодом, который у вас есть) .

Я думаю, что это может сделать его сухим.

(PS. Всегда предпочитайте композицию наследованию. Использование наследования над классом, который может "запускать" ваши объекты, не дает никаких преимуществ)

1 голос
/ 27 февраля 2009

Многие люди делают именно это. Создайте класс, представляющий каждую таблицу, которую все наследуют от одного и того же класса. Базовый класс может обрабатывать загрузку и сохранение данных. Поэтому, если вы хотите загрузить данные, просто вызовите метод загрузки. И вы можете установить и получить доступ к значениям поля по свойствам объектов.

Также есть библиотеки типа hibernate , которые выполняют за вас большую грязную работу.

0 голосов
/ 27 февраля 2009

Вы столкнулись с одним из первых желаний модульности. : -)

Есть два основных решения. Первый - абстрагировать вызов от всех (или большинства) подобных запросов. А потом снова к другому набору запросов. А потом к другому. И так далее. К сожалению, это приводит к многочисленным блокам, которые делают одно и то же: вызывают запрос, проверяют наличие проблем, собирают набор результатов, передают его обратно. Это DAL, но только в некотором роде. Это также не масштабируется.

Второе решение состоит в том, чтобы абстрагировать процесс создания запроса и возврата результата, а затем посмотреть на абстрагирование доступа к данным поверх этого (что в основном означает, что вы создаете что-то, что собирает SQL). Это, скорее всего, станет правильным ORM, а не простым DAL. Это гораздо проще масштабировать.

...