| |
|
|
| | Здравствуйте,
Начал писать новый проект и решил отказаться от функционального подхода в пользу ООП. Столкнулся с такой задачей, есть класс для работы с бд:
class WORK_DB {
// реализация работы с бд
}
|
и есть некий класс для работы с какой то информацией, допустим раздел статей:
class WORK_DOC {
// реализация работы с разделом статей
}
|
во втором классе мне нужно сохранять / выводиться статьи, а они лежат в бд. Соответственно текущая реализация у меня через global
class WORK_DOC {
function show_doc() {
global $WORK_DB;
// вывод списка статей
}
}
|
я понимаю, что использование global не есть хорошо при выбранном подходе. скажите, как правильно реализовать работу с бд по выше описанной ситуации. | |
| |
|
|
| |
|
|
| |
для: reimaxby
(01.08.2015 в 18:11)
| | | у Д. Котерова есть http://dklab.ru/lib/DbSimple/ или PDO | |
| |
|
|
| |
|
|
| |
для: indexer
(02.08.2015 в 18:06)
| | | Посмотрел исходники, у меня интерфейс библиотеки фактически аналогичный. меня интересует правильная реализация с целью не писать абы работало, пример fl.ru более чем показательный (исходники в сети есть, там очень много интересного).
сейчас я пришел к такому решению:
class WORK_DB {
// реализация работы с бд
}
$WORK_DB = new WORK_DB();
class WORK_DOC {
// реализация работы с разделом статей
function list() {
WORK_DB::Query('select * ');
}
}
$WORK_DOC = new WORK_DOC();
|
я пытаюсь грамотно организовать систему, чтобы с ней потом было удобно работать не только мне, но и любому другому программисту. | |
| |
|
|
| |
|
|
| |
для: reimaxby
(01.08.2015 в 18:11)
| | | "Правильный" и "хороший" - настолько эфемерные характеристики, применительно к способу организации кода, что оперировать ими здесь бессмысленно. От слишком многих переменных зависит результирующее значение хорошести и правильности. Более того, существует тенденция к изменению этого значения, по мере увеличения вашего опыта в программировании.
Пишите так, чтобы код работал. Работающий код - хороший код. Со временем станет понятно, удачно ли вписывается этот код в окружение. Если не вписывается - всегда можно переделать. Таким образом постепенно выстроится наиболее подходящая архитектура для данного конкретного проекта в конкретных условиях и вашим текущим уровнем профессионализма.
Пишите больше кода, смотрите на код других, читайте умные книжки - это всё позволит видеть проект ещё на несколько шагов вперёд и принимать более эффективные решения. | |
| |
|
|
