Форумы портала PHP.SU :: Версия для печати

Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Самопис для форума [8]

Форумы портала PHP.SU » Разное » Колонка администратора » Самопис для форума

Страниц (14): В начало « ... 4 5 6 7 [8] 9 10 11 12 ... » В конец

106. DeepVarvar - 18 Декабря, 2014 - 18:37:09 - перейти к сообщению

esterio пишет:

например

Тогда тебе нужно только сделать "конкатенатор" для формирования строки запроса с плейсхолдерами, ибо, как-то так уже работает:

PHP:
скопировать код в буфер обмена

$stmt = $conn->sendQuery(
    'INSERT INTO tbl (a, b, c, d) VALUES (:a, :b, :c, :d)',
    array(
        ':a' => 1,
        ':b' => 2,
        ':c' => 3,
        ':d' => 4
    )
);

107. Panoptik - 18 Декабря, 2014 - 19:00:44 - перейти к сообщению

DeepVarvar пишет:

ибо, как-то так уже работает:

ну в твоем варианте еще нужно гдето брать $stmt и $conn

то есть если речь идет именно о клиентском коде, например в контроллере, то удобней было бы так

Db::insert( ...

нежели

$conn = Db::getConn();
$conn->sendQuery(... // и тут еще кучу чистого sql

108. DeepVarvar - 18 Декабря, 2014 - 19:04:07 - перейти к сообщению

Panoptik пишет:

еще нужно гдето брать $stmt и $conn

В любом варианте потребуется это где-то брать, т.к. у нас один или более коннектов.
И какой именно ты щас в своей модели юзать собрался - знать только тебе.
Кстати $stmt брать не обязательно, просто sendQuery его всегда возвращает, может тебе надо проверить успешен ли инсерт-апдейт, или получить ластинсертайди.
Последнее правда из $conn, но не суть.

А еще, может ты не знаешь - если у нас будет мастер-слейв, то слейв сразу атомарно не получит новую строку в таблице, тем более если ты стартанешь транзакцию, так что тебе еще и из мастера местами придется селект делать, может ты два инсерта в разные таблицы делаешь или еще что-то ))

109. Panoptik - 18 Декабря, 2014 - 19:11:22 - перейти к сообщению

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

высокоуровневые операции

PHP:
скопировать код в буфер обмена

Db::insert($tableName, array $attributes);
Db::update($tableName, array $attributes, $condition = '', $params=array());
 

и низкоуровневые аля

PHP:
скопировать код в буфер обмена

Db::command('Select ... ')->queryAll($fetchAssoc=true, $params=array()); // выбрать всё (многомерный массив)
Db::command('Select ... ', )->queryRow($params=array()); // выбор первой строки (одномерный массив)
Db::command('Select ... ')->queryScalar($params=array()); // выбор первого столбца первой строки - удобно при подсчете количества
Db::command('Select ... ')->queryColumn($params); // создает массив из одного столбца. удобно при выборе списка айдишников
 
Db::command('Insert ... ')->execute($params=array());
Db::command('Update ... ')->execute($params=array());
 

110. DeepVarvar - 18 Декабря, 2014 - 19:12:31 - перейти к сообщению

Panoptik пишет:

высокоуровневые операции

Перечитай выше, я дополнил.

111. Panoptik - 18 Декабря, 2014 - 19:15:41 - перейти к сообщению

DeepVarvar пишет:

А еще, может ты не знаешь - если у нас будет мастер-слейв, то слейв сразу атомарно не получит новую строку в таблице, тем более если ты стартанешь транзакцию, так что тебе еще и из мастера местами придется селект делать, может ты два инсерта в разные таблицы делаешь или еще что-то ))

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

да и идея с несколькими серверами бд - сильно высоко прицел держишь.

112. DeepVarvar - 18 Декабря, 2014 - 19:22:35 - перейти к сообщению

Смысл кешировать что-то кроме мастера когда ты даже не знаешь из какого слейва тебе ответ приедет?

Panoptik пишет:

с несколькими серверами бд - сильно высоко прицел держишь

То Мелкий предложил, я не против.

Panoptik пишет:

Db::command('Select ... ')->queryColumn($params);

PHP:
скопировать код в буфер обмена

$conn->sendQuery('Select ... ', $params)->fetch(\PDO::FETCH_COLUMN);

И остальные примерно так же.
Тебе не хватает стандартного PDO?

113. Bio man - 18 Декабря, 2014 - 20:17:49 - перейти к сообщению

DeepVarvar пишет:

Какими?

сторонними. Или ты думаешь, что зависимостей не будет?

DeepVarvar пишет:

Шило на мыло?

А чем плох поставщик услуг? Лишний килобайт скушает и предотвратит кучу гемороя с созданием объектов?
А вдруг понадобиться заменить, например, реквест, полезешь в исходники заменять?
Лучше пусть будет ООП ради ООП, чем процедуры с наклоном к ООП, в итоге не понятно что.

114. DeepVarvar - 18 Декабря, 2014 - 20:22:32 - перейти к сообщению

Bio man пишет:

предотвратит кучу гемороя с созданием объектов

DeepVarvar пишет:

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

Bio man пишет:

А вдруг понадобиться заменить, например, реквест, полезешь в исходники заменять?

Точно так же - заменишь только файл и делов, если его API будет таким же, то где проблемы?
А ну да, для нового объекта реквеста с левым апи мы будем писать паттерн адаптер.
А потом еще адаптер адаптера адаптера адаптера ))

Bio man пишет:

процедуры с наклоном к ООП

Где? Если фабрику назвали фабрикой, она от этого процедурой не стала.
Или ты о чем?

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

Так же, дабы не казаться голословным или тупо спорщиком.
Я немногим позже скину сюда список принятых от вас и реализованных изменений, доработок и улучшений.
Ато вдруг вам кажется что я только спорю и более ничего.
(Добавление)
Bio man, кстати, RomAndry же добавил уже тебя и Viperа с правами на запись.
Поиграйтесь с контроллерами покамест.
Сами разберетесь - а для других демки сделаете.

115. Bio man - 18 Декабря, 2014 - 20:45:24 - перейти к сообщению

DeepVarvar пишет:

Точно так же - заменишь только файл и делов, если его API будет таким же, то где проблемы?

Постой. Заменишь файл? Ну это не в какие ворота. А если нужно оба реквеста? А файл один на всех? Где гибкость, ради которой и придумали ООП?

DeepVarvar пишет:

Или ты о чем?

ООП без объектов - не ООП. У тебя всё статическое, где надо и не надо.

DeepVarvar пишет:

А ну да, для нового объекта реквеста с левым апи мы будем писать паттерн адаптер.

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

DeepVarvar пишет:

Если я придумаю название своему паттерну проектирования вы от меня отстанете? ))

Тогда какой во всём этом смысл?

116. Мелкий - 18 Декабря, 2014 - 20:56:38 - перейти к сообщению

DeepVarvar пишет:

То Мелкий предложил

а? Когда это? Сам вроде бы писал:

DeepVarvar пишет:

3) Репликациями (да, они нужны, просто хотел обсудить интерфейс и все такое).

А я, казалось бы, недвусмысленно высказался:

Мелкий пишет:

если можете не масштабировать субд - не делайте этого. Если уж весь stackoverflow живёт на двух серверах БД - то мы уж подавно уместимся в один

DeepVarvar пишет:

А что насчет вариантов на стороне мускуля?

Ничего не могу сказать, надо будет поиграться, почитать, на что люди жалуются.

DeepVarvar пишет:

Так вот, какими ты видишь модели?

Так, как это нужно будет в работе.
Модель берёт на себя операции с данными и предоставляет минимально-необходимый публичный интерфейс, которым должно быть удобно пользоваться и из контроллера (конфигурировать, что мы хотим сделать, но ни в коем случае не как мы это хотим сделать (камень в find_by_database_field_name или как там это пишется)), так и вывод данных во вьюхе.
Например, список тем, контроллер:

PHP:
скопировать код в буфер обмена

$rgTopics = forum\topics::filter()
    ->section( $iForumSectionId ) // требуемый подфорум
    ->limit($iFrom, $iPerPage)
    ->order( forum\topics::ORDER_LAST_MESSAGE )
    ->fetch();

Может напоминать query builder, но им не является. Просто API по поиску тем, написанный на языке предметной области. Методы между filter и fetch определяют, что хотим получить. Как ищем - определяет только сам fetch и никаких средств контроля со стороны контроллера не предполагает.
Возвращает итератор, итератор предоставляет API для отдельной темы, удобный для вывода.

117. DeepVarvar - 18 Декабря, 2014 - 21:00:26 - перейти к сообщению

Bio man пишет:

где надо и не надо

Я аргументировал где надо и почему. С вашей стороны я слышу только - ООП без объектов - не ООП.
Странно получается.
А еще - ну не лазий ты в ядро, статики будешь видеть намного меньше ))
Да, именно в ядре статики много, но там и подход совершенно иной.
Ты просто не впихнешь туда что-то "классическое", т.к. оно будет невпихуемым.

Bio man пишет:

Тогда какой во всём этом смысл?

Выше ответил.
(Добавление)

Мелкий пишет:

если можете не масштабировать субд - не делайте этого

Можем и НЕ, но в целом в голове уже картинка сложилась. Ленивые коннекты легко вписываются в getConnection($type).
Другое дело - как на это будут реагировать другие.
Ведь это им следить придется за тем какой коннект им нужен в какой момент.

Мелкий пишет:

Ничего не могу сказать, надо будет поиграться, почитать, на что люди жалуются.

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

Мелкий пишет:

Модели - Так, как это нужно будет в работе.

Ухты ))
Я так же у себя и лепил.
Только называется у меня это - хелперы.
Ждем что скажут другие.

118. armancho7777777 - 19 Декабря, 2014 - 19:10:05 - перейти к сообщению

Bio man пишет:

Лучше пусть будет ООП ради ООП, чем процедуры с наклоном к ООП

119. DeepVarvar - 24 Декабря, 2014 - 11:50:23 - перейти к сообщению

Друзья!

Нужна глобальная помощь на клиентской стороне по следующим пунктам:

1) Выбор инструмента для js-обвязки на клиенте.
............а) Самый тупой вариант - взять jquery и более ничем не обмазываться.
............б) Запилить на чистом.
............в) Другие варианты?

2) Глобальный биндер (слушатель) сабмита форм.
Предлагаю, что слушать он будет а-ля $(document).on('submit', 'form.binded', function() { ...
Брать action и method прямо из формы, принимать и обрабатывать прилетевший JSON с разными плюшками.

Пока все.
Ибо преследуются цели необходимые непосредственно сейчас.

Выжимка:

1) На что клиента повесим?
2) Кто возьмется запилить биндер?

120. tuareg - 24 Декабря, 2014 - 11:56:33 - перейти к сообщению

DeepVarvar пишет:

1) На что клиента повесим?

Лучше jQuery всем проще будет.