Взаимодействие с базой данных с использованием слоев разделения (PHP и WordPress) - PullRequest
3 голосов
/ 03 октября 2011

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

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

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

Я пишу такие классы, как

Table
Column
Row

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

$column = new \Namespace\Data\Column ( /* name, type, null/non-null, etc... */ );
$myTable = new \Namespace\Data\Table( /* name, column objects, and indexes */ );

\Namespace\TableModel.create($myTable);

Мои вопросы ...

Кто-то еще уже что-то написал, чтобы обеспечить некоторое разделение между разными слоями?

Если нет, поможет ли мой подход вообще в долгосрочной перспективе или я теряю время; я должен сломать и жестко закодировать SQL как все остальные?

Если это поможет мне написать это самостоятельно, есть ли какой-нибудь подход, который я мог бы предпринять, чтобы справиться с этим более эффективно?

Ответы [ 2 ]

0 голосов
/ 03 октября 2011

Если честно, я бы просто жестко закодировал SQL, потому что:

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

  2. Мы не живем в идеальном мире . Слишком много абстракций - рано или поздно - приведет к производительности и другим проблемам, о которых я даже не думаю пока. Будь проще. Кроме того, используя SQL, вы можете извлечь выгоду из некоторых «взломов» производительности, которые, возможно, не будут работать для других систем.

  3. SQL - это общепринятый стандарт, который уже можно рассматривать как уровень абстракции . например, есть даже возможность доступа к графику Facebook через SQL-подобный синтаксис (см. FQL ). Если вы захотите перейти на другой источник данных, вы наверняка найдете слой, который в любом случае поддерживает SQL-синтаксис! В этом смысле вы могли бы даже сказать, что SQL уже является неким уровнем абстракции .

Но: если вы решили использовать SQL, обязательно используйте WordPress '$wpdb. Используя это, вы на безопасной стороне, так как WordPress заботится о подключении к базе данных, формировании запросов и т. Д. Если однажды WordPress решит перейти с баз данных на что-то другое, им потребуется создать $wpdb - слой к этому новому источнику - для обратной совместимости. Кроме того, многие общие запросы уже находятся в $wpdb как функции (например, $wpdb->insert()), поэтому нет прямой необходимости жестко кодировать SQL.

Если, однако, вы решите использовать такой уровень абстракции: в Википедии больше информации .

Обновление: Я только что обнаружил, что CMS Drupal использует уровень абстракции базы данных - но они все еще используют SQL для формирования своих запросов для всех различных баз данных! Я думаю, это ясно показывает, как SQL уже можно использовать в качестве уровня абстракции.

0 голосов
/ 03 октября 2011
...