поэтому я пишу класс DataBase который будет слоем инкапсуляции между PHP Controller и MySQL View .
interface iDataBase { public function drug($action, $drug); public function company($action, $company); public function activeIngredient($action, $activeIngredient); }
Сначала я думал о том, чтобы сделать все сеттеры и геттеры отдельными, как getAllDrugs (), updateDrug (), removeDrug (), getForUpdate (), getDrug () и так один, но потом я понял, что я загрязняю интерфейс базы данных со слишком большим количеством функций, плюс это очень мелкомасштабная версия, я рассматриваю возможность добавления гораздо большего числа классов и гораздо более функциональных возможностей. Таким образом, вместо использования множества функций, которые я только что установил для 3. $action , определит, что именно пользователь хочет делать с определенным классом. поэтому на данный момент возможны следующие действия: "add", "getAll", "getForUpdate", "update", "remove"
но эти функции, замаскированные в $action имеют разные вещи, поэтому их результат возврата различен, а второй аргумент также может быть другим.
Является ли мое решение хорошей практикой? Я уверен, что у многих из вас была такая же проблема, как вы ее решили? Возможны ли какие-либо проблемы?
PS Drug, Company, ActiveIngredient – все классы
Функция должна иметь четко определенные, узкие обязанности с четко определенными минималистскими типами возврата. Если вы начнете создавать «божественные функции», которые делают все и кухонную раковину, в зависимости от того, какие аргументы вы проходите, вы сильно входите на территорию труднодоступного спагетти-кода. Вам не нужна функция, которая выполняет A и возвращает B, если вы передаете ее X, но C и возвращает D, если вы передаете ее Y и т. Д. …
Это хорошая идея, чтобы начать бетон и обобщать с течением времени, когда вы видите похожие шаблоны. Итак, создайте нужные вам методы:
public function findUserById($id) public function findUserByEmail($email) public function updateCompanyName($id, $newName)
Если вы обнаружите, что у вас есть общий код между этими функциями, унифицируйте код за кулисами, чтобы он был DRY:
public function findUserById($id) { return $this->find('SELECT * FROM user WHERE id = ?', $id); } public function findUserByEmail($email) { return $this->find('SELECT * FROM user WHERE email = ?', $email); } protected function find($query, $arg) { ... }
Не начинайте наоборот, думая, что вам «нужны только X, Y и Z», которые кажутся достаточно похожими, чтобы быть объединенными в один метод, а затем выяснение наличия небольших различий между X, Y и Z и засорения вашего кода специальные случаи для каждого. Это просто приводит к функциям, которые являются либо гигантскими, либо вообще общими, они в основном ничего не делают сами по себе.
То, что вы, вероятно, ищете, называется TableDataGateway (акцент мой):
Шлюз данных таблицы содержит все SQL для доступа к одной таблице или представлению: выбирает, вставляет, обновляет и удаляет. Другой код вызывает его методы для всего взаимодействия с базой данных.
Это означает, что у вас будет один универсальный адаптер базы данных, например объект PDO. Вы вводите это в свои различные TDG. Затем TDG использует этот адаптер для данных CRUD из базы данных.
class CompanyTableGateway { private $dbAdapter; public function __construct(DBAdapter $dbAdapter) { $this->dbAdapter = $dbAdapter; } public function create($name, $street, $whatever) { $this->dbAdapter->exec( 'INSERT INTO companies …' ); } public function findById($id) { return $this->dbAdapter->exec( sprintf('SELECT * from companies where id = %d', $id) ); } // more methods … }
Если у вас несколько таких шлюзов, вы можете абстрагировать общую CRUD-логику в абстрактном классе, а затем расширить от нее конкретные шлюзы.
Затем вы будете использовать TableModule или аналогичный другой объект для вызова методов на отдельных шлюзах.
Бесконечное обсуждение «Разделение проблем и принцип одиночной ответственности».
Разделение проблем (SoC) – это процесс разбивки компьютерной программы на отдельные функции, которые как можно меньше перекрывают функциональность. Вызывает озабоченность любой интерес или фокус в программе. Как правило, проблемы являются синонимом функций или поведения. http://en.wikipedia.org/wiki/Separation_of_concerns
Единый принцип ответственности (СРП) – каждый объект должен нести единую ответственность и что все его услуги должны быть узко согласованы с этой ответственностью. На некотором уровне Cohesion считается синонимом SRP. http://en.wikipedia.org/wiki/Single_responsibility_principle
Постарайтесь получить лучшее из того и другого, и соответствующим образом моделируйте свои классы.
То, что я бы рекомендовал вам сделать, это сделать глобальный класс базы данных, который управляет базовым вводом / выводом базы данных, а затем расширяет его до каждой таблицы.
Примером этого может служить таблица «Пользователи». Что вы можете сделать с этой таблицей?
Затем вы расширите класс Super Database Class с классом пользователей, который будет иметь геттеры и сеттеры для каждой функции, которую вы хотите иметь, то есть:
class Users extends DatabaseClass { public function update ( $params ) { // Make the code for an update, and let the SuperClass execute the code. ... } public function add ( $params ) { ... } public function delete ( $params ) { ... } }
Это позволит вам позже, легко добавить дополнительные функции в таблицу Users и оптимизировать запросы специально для таблицы / данных, которые вы используете.