2013-03-09 2 views
0

Предположим, у меня есть класс под названием Books. Внутри этого класса у меня есть метод, который выбирает название, цену и категорию одной книги или нескольких книг. Так что-то вроде этого:Написание адаптивных методов PHP?

public function fetchRows() { 
    $sql = $con->prepare("SELECT Title, Price, Category FROM Books"); 
    $sql->execute(); 
    return $sql->fetchAll(); 
} 

Все отлично и хорошо, но позволяет сказать, что теперь я хочу, чтобы принести еще одну строку, order результат и limit количество возвращаемых строк. Написание другого метода только для этого будет работать, но тогда это приведет к смешному количеству методов, и это просто беспорядочно и не соответствует правилу DRY. Я мог бы использовать аргументы для настройки инструкции prepare, тогда я бы, вероятно, закончил тем, что написал весь запрос внутри аргумента, и это тоже не кажется твердым и чистым.

Мой вопрос в том, как я могу написать/структурировать методы/классы, которые адаптируются к тому, что пытается получить конечный пользователь?

Извините, что это действительно не вопрос к конкретной проблеме. Я прочитал некоторые материалы о своей проблеме, но мне сложно обернуть этот шаблон вокруг моей головы, и я надеюсь, что кто-то может предложить объяснение или пример, которые могут помочь мне понять это.

+1

Да, нередко у вас будет отдельное абстракция для взаимодействия с базами данных. Итак, еще один класс, вы можете передать все свои параметры и обработать все запросы db с помощью простого API-интерфейса. – kalpaitch

ответ

1

Считаете ли вы использование ORM (Object Relational Mapper), который находится поверх вашей базы данных? Я очень рекомендую Doctrine 2 http://www.doctrine-project.org. Таким образом, вы можете рассматривать строки в своей таблице базы данных как объекты: все взаимодействие с базой данных абстрагируется (вы все равно можете запускать SQL-запросы, если вам нужно).

В случае, если вы не знакомы с понятиями ORMs, доктрина позволяет писать код так:

$user = new User(); 
$user->username = 'test'; 
$user->email = '[email protected]'; 
$entityManager->persist($user); 
$entityManager->flush(); 

Вы просто запустить INSERT INTO user (username, email) VALUES ('test', '[email protected]'); без написания SQL.

Кроме того, пользователи могут быть получены следующим образом:

$user = $entityManager->getRepository('User')->findOneByUsername('test')

$user = $entityManager->getRepository('User')->findOneByEmail('[email protected]')

Эти Методы поиска генерируются автоматически для вас, на основе полей, присутствующих на столе пользователя, помогая вам сохранить код DRY.

+0

Downvoter: Помогите объяснить, почему? Я чувствую, что это отвечает на вопрос. – ChrisC

+0

Я не сделал этого, но я думаю, что проблема заключается в том, что вы предлагаете добавлять методы поиска, в то время как OP обеспокоен их добавлением (cf ", что приведет к нелепому количеству методов"). Скорее всего, это поможет OP показать, как использовать объекты DQL и Criteria, собранные с пользовательского ввода. – Gordon

+0

Методы поиска автоматически генерируются Doctrine: им не нужно писать пользователем. – ChrisC

-1

подходит к тому, что пользователь пытается получить?

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

В противном случае вы начинаете изобретать колесо. И я сомневаюсь, что у вас действительно есть много функций с такими параметрами, если честно.

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

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

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

$result = PDOQuery::create('* FROM config')->limit(2); 

$result->orderBy('`option`'); 

$result->aliasNames(['option' => 'name'], $removeOther = true);  

foreach ($result as $row) { 
    print_r($row); 
} 

Это просто образцовое, код будет только предоставить строки в ассоциативных массивах:

Array 
(
    [name] => Insert Option 50e60ca17bdf4 
) 
Array 
(
    [name] => Insert Option A 50e78a79ead49 
) 

только выполняется, когда дело доходит до Еогеаспа (например, вы можете передать, что в поле зрения, и если view не нужен, запрос базы данных никогда не выполняется).

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

Вы можете сделать итератор сложным итератором, чтобы, если запрос был выполнен, вы можете применить ограничение на результат вместо повторного выполнения запроса. И что "нет.

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

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

Смежные вопросы