как отделить SQL от PHP-кода

Question

У меня есть класс, который помогает мне работать с пользователями.Например:

$user = new User("login","passw");
$name = $user->getName();
$surname = $user->getSurname();
$table = $user->showStats();

Все эти методы имеют SQL-запросы внутри.Некоторые действия требуют только одного sql запроса, некоторые - более одного.Если структура базы данных изменится - будет сложно изменить все запросы (класс длинный).Поэтому я подумал об удалении запросов SQL от этого класса.Но как это сделать?

Прочитав этот вопрос Я знал о хранимых процедурах.Значит ли это, что теперь для одного действия требуется только один SQL-запрос (вызов хранимой процедуры)?Но как организовать отделение sql от php?Должен ли я хранить sql-запросы в массиве?Или это может быть класс sql-запросов.Если да, то как организовать этот класс (возможно, по какому шаблону я должен научиться)

Answer 1

Это удивительно обширная тема, но у меня есть несколько советов, которые помогут вам на вашем пути:

Вам следует изучить объектно-реляционное отображение, в котором объект автоматически генерирует SQL-запросы.Просмотрите обзор статей Object-Relational Mapping и Active Record .Это сохранит минимальный код вашей базы данных и облегчит изменение структуры таблицы.

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

В любом случае, что угоднометод, который вы выбираете, я рекомендую вам хранить логику базы данных в нескольких классах "Model".Похоже, вы уже делаете что-то похожее на это.Основная идея заключается в том, что каждая модель инкапсулирует логику для определенной области базы данных.Традиционно каждая модель отображается в одну таблицу в БД - так работает класс активных записей Ruby on Rails.Это хорошая стратегия, поскольку она разбивает логику вашей базы данных на простые маленькие «кусочки».Если вы сохраните всю логику запросов к базе данных в одном файле, она может быстро выйти из-под контроля и превратиться в кошмар обслуживания - поверьте мне, я была там!

Чтобы лучше понять "большой"picture ", я рекомендую вам потратить некоторое время на чтение веб-архитектуры Model-View-Controller (MVC).Вы также захотите посмотреть на установленные PHP MVC-фреймворки, такие как CodeIgniter , Кохаха , CakePHP и т. Д. Даже если вы не используете одну из них - хотяЯ рекомендую это сделать - было бы полезно посмотреть, как эти структуры организуют ваш код.

Answer 2

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

Хороший ответ на вопрос, как реализовать это, будет слишком длинным для этого пространства, поэтому я выложу паруориентированных на PHP ссылок:

travis swicegood - Шаблон репозитория в PHP

Джон Лебенсолд - Шаблон репозитория в PHP

Answer 3

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

И Фауст, и Джастин Этьер дают хорошие рекомендации: «Как мне отделить доступ к моей базе данных от кода моего приложения» - это один из самых старых и наиболее часто задаваемых вопросов в веб-разработке.

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

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

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

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

Answer 4

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