Я все в состоянии понять. Вы увидели статичное свойство и у вас сразу в голове появилось "синглтон", больше ничего не знаю, но наличие кардинального отличия одного от другого вы понять не можете. В моем случае осущевтляется еденственное соедиение к БД.
Тоже синглтон?)) http://pastebin.com/DYgjyn1u
После этой фразы можно успешно увольнять человека)))
Ахаха... Да да, синглтон бл..))
Где вы нашли singlton-like сущность? О каком DI вы говорите, если ни от каких внешних зависимостей объект не зависит. Хотя нет, давайте вставим туда внешнюю зависимость, сохраним ее в registry, или вообще начнем ее таскать с момента инициализации, но будем ее передавать.
if (!isset($this->_db)){
$class = "app_db_".APP_SQL_SERVER;
$this->_db = new $class;
}
return $this->_db;
// ...
self::$_mysqli = new mysqli(
APP_MYSQLI_HOST,
APP_MYSQLI_USER,
APP_MYSQLI_PASS,
APP_MYSQLI_DB
);
утверждение полностью противоречит идеологии open source
или мы делаем форк, сохранив API и описав дополнительные фичи
В огороде бузина, а в городе - дядька.
я глубоко знаю фреймворк, на котором работаю. я его выбирал.
да, особенно кодеры - они очень сильно выигрывают, только DBA знает структуру базы, там >100 таблиц,
Ситуация такая: у нас фильтр и пангинация по таблице, например, users. Для получения данных делаем join нескольких других крупных таблиц - address, profile.
Показал уже: http://pastebin.com/DYgjyn1u , (было выше). Нужно мыслить не на уровне того, используется ли константа сейчас, а на уровне того, насколько объекты быстро могут быть дополнены с сохранением обратной совместимости и минимальными трудозатратами. Понадобиться исключительно новое соединение, то вполне быстро можно внести изменения, как указанные выше, так и просто поменяв метод коннекта и геттера объекта.
<?php
/**
* MySQLi object
* @var mysqli
*/
protected static $_default_mysqli;
/**
*
* @var mysqli
*/
protected $_current_mysqli;
/**
* (non-PHPdoc)
* @see app_db_interface::connect()
*/
public function connect($host = null, $user = null, $password = null, $db = null, $set_as_default_connection = true)
{
mysqli_report(MYSQLI_REPORT_ALL & ~MYSQLI_REPORT_INDEX);
if (!isset($host))
{
if (isset(self::$_default_mysqli))
{
$this->_current_mysqli = self::$_default_mysqli;
return $this;
}
$host = APP_MYSQLI_HOST;
$user = APP_MYSQLI_USER;
$password = APP_MYSQLI_PASS;
$db = APP_MYSQLI_DB;
}
try {
$this->_current_mysqli = new mysqli(
$host,
$user,
$password,
$db
);
$this->_current_mysqli->set_charset(APP_DEFAULT_SQL_CHARSET);
if (defined("APP_DEVELOPMENT_VERSION") && APP_DEVELOPMENT_VERSION)
{
$this->_current_mysqli->query("set profiling = 1;");
$this->_current_mysqli->query("set @@profiling_history_size = 100;");
}
}
catch(mysqli_sql_exception $e)
{
throw new app_exception($e->getMessage(), 503);
}
if ($default_connection)
{
self::$_default_mysqli = $this->_current_mysqli;
}
return $this;
}
//...
/**
* Возвращает объект MySQLi
* @return mysqli
*/
protected function _mysqli()
{
if (!isset($this->_current_mysqli))
{
$this->connect();
}
return $this->_current_mysqli;
}Согласен, справедливо для одного проекта, который является единственным в разработке и коммерческим. Но если бы проект был общедоступным, и использовалась та или иная либа, то нужно сначала вложить в эту либу, а потом ее юзать, поскольку либа идет отдельно от проекта. Скажем для внедрения новых возможностей в gnome нужно профиксить gtk. Сначала реквист на дополнение gtk или вклад, потом уже допиливание gnome.
пока libevent не поправили, anight спокойно прикладывал в исходники fpm патченый libevent, никто не возражал
а в случае со своим велосипедом в него надо вложиться в тысячу раз больше. обычно там есть всё что нужно, чуть что, всегда можно форкнуть. в тех же линукс дистрибутивах в каждом своя версия гнома со своими патчами. в этом и есть идея, в либе реализовано 99% потребностей, а остальные 1 можно решить форком, чтобы не перегружать основной функционал.
Форкают от безысходности, если пакет медленно обновляется или произошел конфликт девелоперов (простой пример ffmpeg vs libav) . А по поводу SQL запросов длинной в километр) Имхо, SQL запрос нагляден в отличии от QB, а также не ограничивает в использовании имеющихся SQL механизмов, особенно когда дело доходит до триггеров и функций. Разработчик заводится в рамки этого "универсального" QB, а также не защещен от багов, плюс ко всему, когда наступает момент, что возможности QB не отвечают потребностям разработчика и хочется все выбросить http://phpclub.ru/talk/threads/Посоветуйте-sql-query-builder.76389/ .
