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
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Самопис для форума [8]
Покинул форум
Сообщений всего: 2493
Дата рег-ции: Нояб. 2011 Откуда: Одесса, Украина
Помог: 131 раз(а)
DeepVarvar пишет:
ибо, как-то так уже работает:
ну в твоем варианте еще нужно гдето брать $stmt и $conn
то есть если речь идет именно о клиентском коде, например в контроллере, то удобней было бы так
Db::insert( ...
нежели
$conn = Db::getConn();
$conn->sendQuery(... // и тут еще кучу чистого sql
----- Just do it
DeepVarvar
Отправлено: 18 Декабря, 2014 - 19:04:07
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Panoptik пишет:
еще нужно гдето брать $stmt и $conn
В любом варианте потребуется это где-то брать, т.к. у нас один или более коннектов.
И какой именно ты щас в своей модели юзать собрался - знать только тебе.
Кстати $stmt брать не обязательно, просто sendQuery его всегда возвращает, может тебе надо проверить успешен ли инсерт-апдейт, или получить ластинсертайди.
Последнее правда из $conn, но не суть.
А еще, может ты не знаешь - если у нас будет мастер-слейв, то слейв сразу атомарно не получит новую строку в таблице, тем более если ты стартанешь транзакцию, так что тебе еще и из мастера местами придется селект делать, может ты два инсерта в разные таблицы делаешь или еще что-то ))
Покинул форум
Сообщений всего: 2493
Дата рег-ции: Нояб. 2011 Откуда: Одесса, Украина
Помог: 131 раз(а)
сейчас речь об инкапсуляции, сокрытии твоих кишок, то есть пришел человек, посмотрел интерфейс класса Db и взял то что ему из этого надо в данный момент
Покинул форум
Сообщений всего: 2493
Дата рег-ции: Нояб. 2011 Откуда: Одесса, Украина
Помог: 131 раз(а)
DeepVarvar пишет:
А еще, может ты не знаешь - если у нас будет мастер-слейв, то слейв сразу атомарно не получит новую строку в таблице, тем более если ты стартанешь транзакцию, так что тебе еще и из мастера местами придется селект делать, может ты два инсерта в разные таблицы делаешь или еще что-то ))
так тут же ты можешь кешировать эти данные и вернуть при необходимости, без выполнения запроса, и если у тебя эти вещи будут инкапсулированы, то допилить некую доп логику будет на порядок легче
да и идея с несколькими серверами бд - сильно высоко прицел держишь.
----- Just do it
DeepVarvar
Отправлено: 18 Декабря, 2014 - 19:22:35
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Смысл кешировать что-то кроме мастера когда ты даже не знаешь из какого слейва тебе ответ приедет?
Panoptik пишет:
с несколькими серверами бд - сильно высоко прицел держишь
Покинул форум
Сообщений всего: 2751
Дата рег-ции: Июль 2010 Откуда: Даугавпилс, Латвия
Помог: 52 раз(а)
DeepVarvar пишет:
Какими?
сторонними. Или ты думаешь, что зависимостей не будет?
DeepVarvar пишет:
Шило на мыло?
А чем плох поставщик услуг? Лишний килобайт скушает и предотвратит кучу гемороя с созданием объектов?
А вдруг понадобиться заменить, например, реквест, полезешь в исходники заменять?
Лучше пусть будет ООП ради ООП, чем процедуры с наклоном к ООП, в итоге не понятно что.
DeepVarvar
Отправлено: 18 Декабря, 2014 - 20:22:32
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Bio man пишет:
предотвратит кучу гемороя с созданием объектов
DeepVarvar пишет:
В частности - напомню, что моя защита статики касается только глобально используемых сингтонов-инстансов, остальные то у нас лениво лежат в App ну и коннекты в отдельном месте.
Bio man пишет:
А вдруг понадобиться заменить, например, реквест, полезешь в исходники заменять?
Точно так же - заменишь только файл и делов, если его API будет таким же, то где проблемы?
А ну да, для нового объекта реквеста с левым апи мы будем писать паттерн адаптер.
А потом еще адаптер адаптера адаптера адаптера ))
Bio man пишет:
процедуры с наклоном к ООП
Где? Если фабрику назвали фабрикой, она от этого процедурой не стала.
Или ты о чем?
Если я придумаю название своему паттерну проектирования вы от меня отстанете? ))
Это конечно же была шутка.
По делу - можете не беспокоится, как видно из большинства заданных в этой теме вопросов, единственное отличие от классических архитектур - больше статических обращений к сущностям, в остальном все то же самое.
Так же, дабы не казаться голословным или тупо спорщиком.
Я немногим позже скину сюда список принятых от вас и реализованных изменений, доработок и улучшений.
Ато вдруг вам кажется что я только спорю и более ничего. (Добавление) Bio man, кстати, RomAndry же добавил уже тебя и Viperа с правами на запись.
Поиграйтесь с контроллерами покамест.
Сами разберетесь - а для других демки сделаете.
Покинул форум
Сообщений всего: 2751
Дата рег-ции: Июль 2010 Откуда: Даугавпилс, Латвия
Помог: 52 раз(а)
DeepVarvar пишет:
Точно так же - заменишь только файл и делов, если его API будет таким же, то где проблемы?
Постой. Заменишь файл? Ну это не в какие ворота. А если нужно оба реквеста? А файл один на всех? Где гибкость, ради которой и придумали ООП?
DeepVarvar пишет:
Или ты о чем?
ООП без объектов - не ООП. У тебя всё статическое, где надо и не надо.
DeepVarvar пишет:
А ну да, для нового объекта реквеста с левым апи мы будем писать паттерн адаптер.
Не забывай что реквест приведён как пример. На деле может понадобится подменить любой класс. И если, это действительно нужно - можно написать адаптер, ничего плохого в этом не вижу.
DeepVarvar пишет:
Если я придумаю название своему паттерну проектирования вы от меня отстанете? ))
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
DeepVarvar пишет:
То Мелкий предложил
а? Когда это? Сам вроде бы писал:
DeepVarvar пишет:
3) Репликациями (да, они нужны, просто хотел обсудить интерфейс и все такое).
А я, казалось бы, недвусмысленно высказался:
Мелкий пишет:
если можете не масштабировать субд - не делайте этого. Если уж весь stackoverflow живёт на двух серверах БД - то мы уж подавно уместимся в один
DeepVarvar пишет:
А что насчет вариантов на стороне мускуля?
Ничего не могу сказать, надо будет поиграться, почитать, на что люди жалуются.
DeepVarvar пишет:
Так вот, какими ты видишь модели?
Так, как это нужно будет в работе.
Модель берёт на себя операции с данными и предоставляет минимально-необходимый публичный интерфейс, которым должно быть удобно пользоваться и из контроллера (конфигурировать, что мы хотим сделать, но ни в коем случае не как мы это хотим сделать (камень в find_by_database_field_name или как там это пишется)), так и вывод данных во вьюхе.
Например, список тем, контроллер:
Может напоминать query builder, но им не является. Просто API по поиску тем, написанный на языке предметной области. Методы между filter и fetch определяют, что хотим получить. Как ищем - определяет только сам fetch и никаких средств контроля со стороны контроллера не предполагает.
Возвращает итератор, итератор предоставляет API для отдельной темы, удобный для вывода.
----- PostgreSQL DBA
DeepVarvar
Отправлено: 18 Декабря, 2014 - 21:00:26
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Bio man пишет:
где надо и не надо
Я аргументировал где надо и почему. С вашей стороны я слышу только - ООП без объектов - не ООП.
Странно получается.
А еще - ну не лазий ты в ядро, статики будешь видеть намного меньше ))
Да, именно в ядре статики много, но там и подход совершенно иной.
Ты просто не впихнешь туда что-то "классическое", т.к. оно будет невпихуемым.
Bio man пишет:
Тогда какой во всём этом смысл?
Выше ответил. (Добавление)
Мелкий пишет:
если можете не масштабировать субд - не делайте этого
Можем и НЕ, но в целом в голове уже картинка сложилась. Ленивые коннекты легко вписываются в getConnection($type).
Другое дело - как на это будут реагировать другие.
Ведь это им следить придется за тем какой коннект им нужен в какой момент.
Мелкий пишет:
Ничего не могу сказать, надо будет поиграться, почитать, на что люди жалуются.
В настоящий момент я всеравно эмулирую мастер и слейв, даже для синглового коннекта.
Так что внутряки переписывать не придется когда реплики пойдут.
Мелкий пишет:
Модели - Так, как это нужно будет в работе.
Ухты ))
Я так же у себя и лепил.
Только называется у меня это - хелперы.
Ждем что скажут другие.
Покинул форум
Сообщений всего: 4526
Дата рег-ции: Февр. 2011 Откуда: Москва
Помог: 221 раз(а)
Bio man пишет:
Лучше пусть будет ООП ради ООП, чем процедуры с наклоном к ООП
+1
DeepVarvar
Отправлено: 24 Декабря, 2014 - 11:50:23
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
Друзья!
Нужна глобальная помощь на клиентской стороне по следующим пунктам:
1) Выбор инструмента для js-обвязки на клиенте. ............а) Самый тупой вариант - взять jquery и более ничем не обмазываться. ............б) Запилить на чистом. ............в) Другие варианты?
2) Глобальный биндер (слушатель) сабмита форм.
Предлагаю, что слушать он будет а-ля $(document).on('submit', 'form.binded', function() { ...
Брать action и method прямо из формы, принимать и обрабатывать прилетевший JSON с разными плюшками.
Пока все.
Ибо преследуются цели необходимые непосредственно сейчас.
Выжимка:
1) На что клиента повесим?
2) Кто возьмется запилить биндер?
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.