Самопис для форума

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

-----
Шта? Репозиторий?

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

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

Db::insert( ...

нежели

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

-----
Just do it

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

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

-----
Шта? Репозиторий?

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

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

-----
Just do it

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

-----
Шта? Репозиторий?

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

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

-----
Just do it

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

-----
Шта? Репозиторий?

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

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

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

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

-----
Шта? Репозиторий?

Постой. Заменишь файл? Ну это не в какие ворота. А если нужно оба реквеста? А файл один на всех? Где гибкость, ради которой и придумали ООП?
ООП без объектов - не ООП. У тебя всё статическое, где надо и не надо.
Не забывай что реквест приведён как пример. На деле может понадобится подменить любой класс. И если, это действительно нужно - можно написать адаптер, ничего плохого в этом не вижу.
Тогда какой во всём этом смысл?

(Отредактировано автором: 18 Декабря, 2014 - 21:00:21)

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

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



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


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

-----
PostgreSQL DBA

Я аргументировал где надо и почему. С вашей стороны я слышу только - ООП без объектов - не ООП.
Странно получается.
А еще - ну не лазий ты в ядро, статики будешь видеть намного меньше ))
Да, именно в ядре статики много, но там и подход совершенно иной.
Ты просто не впихнешь туда что-то "классическое", т.к. оно будет невпихуемым.
Выше ответил.
(Добавление)
Можем и НЕ, но в целом в голове уже картинка сложилась. Ленивые коннекты легко вписываются в getConnection($type).
Другое дело - как на это будут реагировать другие.
Ведь это им следить придется за тем какой коннект им нужен в какой момент.
В настоящий момент я всеравно эмулирую мастер и слейв, даже для синглового коннекта.
Так что внутряки переписывать не придется когда реплики пойдут.


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

-----
Шта? Репозиторий?

+1

Друзья!

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

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

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

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

Выжимка:

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

-----
Шта? Репозиторий?

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