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


А baldina как предпочитает видеть этот кусок?

ksnk, дело вовсе не в драйверах и не обертках. это вопрос не вкуса, а архитектуры.
важно не как оно выглядит (это тоже важно, но во вторую очередь), а как структурно устроено.
я сказал, что singleton это плохо масштабируемое решение, поэтому должен применяться как лекарственный яд - строго по назначению малыми дозами.


к несчастью к php это в малой степени относится (к несчастью - потому что провоцирует на применение). в php проблема возникает лишь в случае зависимости объектов, при которой требуется определенный порядок инициализации. в случае решения на основе синглтонов некому этот порядок обеспечить и контролировать.

я вижу решение в использовании единственного "как бы" синглтона - объекта типа Application, который и порядок инициализации обеспечивает, и предоставляет доступ к объектам, глобальным в контексте приложения, и сам является масштабируемым.

Добавлено через 5 минут и 23 секунды


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

Наводящий вопрос.

Каким образом оно масштабируется?

Добавлено через 1 минуту и 57 секунд

Увы, не для "красиво". А для того, чтобы не было мучительно больно в процессе поддержки и расширения приложения 

добавлением метода в класс Application
само приложение может быть масштабировано созданием нескольких объектов Application (хотя к задачам веб это думаю не относится))

Итого? получаем кучку тех же самых синглтонов?   
В чем тут отличие от масштабирования приложений на пхп?
И как порядок инициализации может мешать подобному масштабированию?  

Красота не бывает абстрактной. Она обязана приносить пользу   

В программировании "красивая" польза будет
-- поддержка проекта, в дальнейшем, чужими людьми. Решается достаточной документацией и комментариями.
-- возможность дальнейшего роста проекта, добавление новых возможностей, фич. Решается проектированием и выбором масштабируемых решений.
-- повторная используемость кода. Это когда код (классы, функции и кусочки кода) в меру тупо и без особых изменений могут быть скопированы в другой, новый проект и там заработают правильно и достаточно эффективно. 

Вот эта третья красивость тянет за собой минимизацию зависимостей от окружения. Слова, которые определяются в других классах-функциях, должны по возможности исключаться, или быть изолированы в отдельном месте класса - функции... Так чтобы это не противоречило остальным факторам "красивого кода".


Это сообщение отредактировал(а) ksnk - 19.3.2013, 17:34

не php, а web. и если бы были, уже кто-нить придумал бы соотв. архитектурное решение
пример: приложение как расчетный модуль. если приложение организовано через единственный объект, можно завести еще один объект и параллельно решать две однотипные задачи. а если приложение содержит ряд синглтонов (или просто глобальных переменных)? 


порядок инициализации может мешать масштабированию, если он требуется, но никто им не управляет

В php нет тредов.
Поэтому завести еще один объект и решать параллельно можно только вместе с новым процессом.

А поскольку процессы между собой изолированы, то никаких сложностей не возникает (если вы, конечно, не применяли ухищрений, например, с shmop) ни с рядом синглтонов, ни с глобальными переменными.


Это не относится к работе синглтонов, пула и т.п. в рамках скрипта.

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

Fortop, что в твоём понимании масштабирование..? Просто читаю и чем больше, тем хуже начинаю понимать   

а доступ к базе данных к этому не относится?

во-первых, параллельно можно работать кооперативно. во-вторых, речь шла об архитектуре вообще


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

Добавлено через 7 минут и 8 секунд

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

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

итог: создание экземпляра объекта db и т.п. и его предоставление приложению - дело не библиотеки (доступа к бд), а приложения. т.к. библиотека не знает в рамках какой архитектуры она будет работать, а предоставление синглтона на уровне библиотеки (тем более без возможности альтернативного создания объекта) как минимум стимулирует неправильное использование в рамках конкретной архитектуры.

(для простых приложений возможность использования контекста по умолчанию удобно, как это устроено в php_mysql. в процедурном стиле mysqli от этого отказались, т.к. ножик острый)

Это сообщение отредактировал(а) baldina - 19.3.2013, 19:59

В смысле?
Масштабирование это увеличение используемых для решения задачи ресурсов.

Фокус в том, что для многих языков оно доступно через многозадачность в потоках.
Но php не поддерживает подобное решение (и это во многом его плюс).
Т.е. любое масштабирование задачи на php сводится к запуску дополнительных копий скрипта (на этой машине или многих других машинах - не суть важно).
Поэтому у задач на пхп обычно нет тех проблем, на которые пытался ссылаться baldina.

Т.е. конечный php-скрипт с его пространством имен и есть тот самый Application
В многих других языках все не так просто.


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

Добавлено через 5 минут и 17 секунд

Это все справедливо. В частности поэтому я обратил внимание на то, что класс работы с БД не обязан быть синглтоном 
Но применительно к области применения php и конкретно соединения с БД - стараются минимизировать их число для приложения.

Поэтому


Обращаю внимание на фразу "и то не всегда".
Т.е. подключение/адаптер не всегда обязан быть синглтоном 

аа, значит правильно понял.. А зачем мне расширять ресурсы??? Я смотрел много движков где это закладывается, но реально это вообще или очень и очень редко используется... Вот для фреймворков может быть это актуально. А вот для движка для моего сайта вообще не нужно... Я написал класс для управления базой что он и делает... А масштабирование это не только для меня увеличение человека/часов, но и выброшенные деньги   Так что мера должна быть в желаниях

да конечно не обязан(!), но как правило является таковым для простых вопросов (и даже не очень)  т.к. не нужно ни масштабирование ни множественное подключение

Конкретно тебе? Без понятия.

А у нас на 300к уников в сутки виртуалка впала в ступор, пришлось поднимать еще две.

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