|
ООП головного мозга
Наткнулся тут на CodeIgniter и мне это напомнило ООП головного мозга.
public function getData($id = 0, $offset = 0, $limit = 30) {
$result = $this->db->select('table1.id, table2.name')
->from('table1')
->join('table2', 'table2.id=table1.id', 'left');
if ($id) return $result->where('table1.id', (int)$id)->limit(1)->get()->row();
return $result->limit($limit, $offset)->get()->result();
}
SQL на выходе: "SELECT table1.id, table2.name FROM table1 LEFT JOIN table2 ON table2.id = table1.id LIMIT 10, 30" ЗАЧЕМ? Чтобы не учить синтаксис SQL? Неужели он настолько сложный, что нужно делать новый язык и возможно забивать на мощь самого sql ограничивая его собственной реализацией? Да, я долго обходился простыми запросами, но доучить join-ы и прочую мелочь не составило труда. Стоило прочитать на досуге пару страниц. Не, я не понимаю. |
Вероятнее, для того, чтобы иметь возможность не задумываться над правильной обёрткой user-defined данных. Чтобы не заморачиваться над тем, как вычесть два месяца из данной даты. Чтобы не строить трёхэтажную конкатеацию строки в зависимости от различных условий, а обходиться более привычными конструкциями. Чтобы иметь один(!!!) синтаксис для обращения к любой реляционной базе данных, будь она MySQL, MSSQL или Oracle.
Ну, то есть это должно быть в правильной реализации подобных вещей. Судя по ->limit, тут только обёртка над MySQL, и тогда подобное нечто теряет глубинный смысл. Лучше реализовать java-like PreparedStatement и на этом успокоиться. P.S. Если что, я вообще-то большой любитель трёхэтажных запросов с использованием оконных функций, cte и прочей sql-ной радости (: Но подобные обёртки иногда сильно уменьшают количество требуемых проверок в простых запросах. |
причем похоже, что синтаксис SQL все равно надо знать, чтобы составить запрос такой
|
Цитата:
Цитата:
Такие реализации только добавляют ненужные тормоза в программу. И в какой-то момент точно не подойдут или не смогут решить ту или иную задачу. В этот момент и возникает вопрос - wat? |
Повторюсь про отсутствие необходимости обёртки пользовательского ввода. Это действительно очень удобно.
Пример из жизни: проект начинался под неким фреймворком, который изначально разрабатывался под Oracle. Под него было сделано N моделей и прочей полезной лабуды. После чего выяснилось, что заказчику очень нужен MSSQL, "потому что одна наша база уже там крутится, вдруг интегрировать будем". Вместо переписывания килотонн кода потребовалось доработать фреймворк, чтобы он кушал чужой синтаксис. Ещё двух примеров, к сожалению, пока привести не могу (: По поводу дат - да, действительно, есть встроенные конструкции. С одной проблемой - в каждой БД они свои. Я, как MSSQL-щик, испытываю большие трудности, когда мне приходится общаться с MySQL-ными датами, потому что привык работать с dateadd, datediff и прочим своеобразным синтаксисом. Разводить холивар не буду. Добавлю только, что любому такому врапперу обязательно нужна функция execQuery - именно для того, чтобы конструкции языка можно было применять в полной мере. Ещё раз повторюсь, что я сам с удовольствием пишу длинные запросы в виде текста, "потому что так удобнее и быстрее". Но плюсы для начинающих юзеров в таком подходе, несомненно, присутствуют. |
Выносим запросы в методы и не нужно менять килотонны кода. Даже на сложный проект запросов получается не так уже много. Зато мы имеем бонус в виде скорости.
Поэтому не убедил. |
Цитата:
http://ru.wikipedia.org/wiki/ActiveRecord Например part = new Part() part.name = "Sample part" part.price = 123.45 part.save() создает новую запись в таблице parts с данными значениями и нам не важно, какая БД у нас используется, Mysql или MongoDB Что-то в этом есть |
в этих фреймворках полно нагромождения подобных конструкций, единственное для чего позвалительно написать обертки это для INSERT, UPDATE и DELETE
$db->insert('t', $arr) $db->update('t', $arr) $db->delete('t', $id) |
Цитата:
И чтобы один и тот же код работал с разными БД нужна прослойка. Раньше в друпале она была процедурная, а сейчас, после pdo, типа такая как ты привел. Зато можно сайт запустить на какой хочешь базе данных - sqllite, mysql, postgresql, ... |
Цитата:
Для простых запросов можно юзать ->query("SLECT ....") (Это в Zend, в CodeIgniter думаю тоже есть что то подобное) Хочется ещё более высокого уровня абстракции - ORM к вашим услугам. В Yii мне нравится его использовать. В Zend своего нету, но можно доктрину прикрутить. Про CodeIgniter не знаю. Цитата:
Цитата:
|
Цитата:
Да, да, в идеале переносимость на всё и вся. Всё и вся всеядность. В итоге тормоза и завышенные требования к хостингу. Это работает медленно. И медленно из-за этого всё и вся. А вся эта переносимость от неправильной постановки задачи и методов её решения. |
Тогда всё можно на асме писать вообще.
Суть в более высоком уровне абстракции, не только в переносимости. Цитата:
$where = array();
$where[] = '`cpu` LIKE "'.$url.'%"';
$where[] = '`id`!='.$id;
if(!empty($item_catids))
$where[] = '`i2c`.`cat_id` IN ('.implode(',',$item_catids).')';
$query = 'SELECT `cpu` FROM `'.$kernel->pub_prefix_get().'_catalog_'.$kernel->pub_module_id_get().'_items` `items`'
.'JOIN `'.$kernel->pub_prefix_get().'_catalog_'.$kernel->pub_module_id_get().'_item2cat` `i2c` ON `i2c`.`item_id`=`items`.`id`'
.'WHERE '.implode(' AND ',$where);
$result = $kernel->runSQL($query);
while($row = mysql_fetch_assoc($result))
$cpu_list[] = $row;
Неужели такой стиль лучше? |
Tim, а ты yii знаешь?
Что то начал его смотреть, та официальная документация что на их сайте - это что, - все описание что есть? Типа этого должно хватить для освоения? |
micscr,
Немного знаю теперь. У нас проект один на Yii, пришлось разбираться. Мне было легче т.к. я смотрел как остальные модули написаны и делал свой по образцу попутно читая документацию. С документацией действительно не оч хорошо всё. Ещё есть сайт русскоязычного сообщества http://yiiframework.ru/. Там есть пример создания блога http://yiiframework.ru/doc/blog/ru/start.overview Ещё есть API |
Цитата:
Цитата:
Почитай про pdo что ли. Раз уж ты используешь $kernel->, зачем использовать mysql_fetch_assoc, а не $s->fetch(). Как минимум ты будешь в одном стиле писать, про комбу в рукаве я вообще молчу. |
Цитата:
Цитата:
Цитата:
|
micscr,
вот ещё в догонку http://yupe.ru/ . Вроде прикольная штука. Сегодня только нашёл её |
спасибо, гляну, а то что то с первого взгляда немного разочаровало, т.к. объясняется система имхо плохо.
Хотя может мне непривычно, я друпалил до этого, там все по другому, но друпал для программиста идет куда то непонятно куда :( |
micscr,
фреймворк достаточно интересный. да, документация такая что хочется всё бросить |
micscr,
Я даже знаю людей писавших пару лет на CodeIgniter и попробовавших Zend но потом остановившихся на Yii. Сам я больше к Zend склоняюсь. Хочу ещё Symfony попробовать. Цитата:
|
Цитата:
Цитата:
|
Цитата:
|
Цитата:
|
Цитата:
остаётся один вариант - непереносимость к декларативному программированию. |
Цитата:
2) Раз в 2 года они меняют апи, и надо переучиваться. Старые наработки уже не пашут. 8-я версия уже как то с Симфони будет связана. 3) Там смысл что нужно сайт собирать по максимуму модулями. Я приводил пример той сборки, помнишь? В этих всех тонкостях тоже долго разбираться и это ни разу не программирование. Многие даже толкают религию, что в друпал сайте вообще не должно быть "своего" кода от программиста, а только модули с drupal.org. Вот, если не лень читать, недавние бурления. И получается, чтобы собрать нормальный друпал сайт друпалеру надо: - максимально знать настройку модулей, чтобы ими реализовать функционал - если что то нужно изменять, то тут уже нужны глубокие знания как кодить под него - эти глубокие знания получать рискованно, т.к. они все меньше востребованы, и постоянно надо переучиваться, т.к. меняется апи. Вон yii я смотрю до 2015 продлили поддержку текущей версии, прям как прозрение. Но зато у друпала есть классная админка, через которую владелец сайта может очень мощно управлять контентом сайта и настройкой сайта. И куча модулей, готовых к работе, подключением из админки. А у yii есть что то для админки сайта? А то мне этот момент не ясен, в друпале самая масса усилий потрачена именно на реализацию админки и идей управления контентом, а в yii что самому писать все? Хотя бы управление синонимами, метатегами, титлами, блоками,... ? |
Цитата:
Цитата:
Сейчас пока CMS на фреймворк поставлю. Кусок кода который я привёл как раз из неё )) Нужно что то с этим делать |
Цитата:
must die. |
Цитата:
Цитата:
|
Хватит засирать мою тему мусором про друпал, с которым было все понятно ещё лет пять назад.
Скоро перепишу ядро и может поделюсь с миром своей админкой. Дизайн уже полностью проработан и переделываться не будет, только улучшения и добавление модулей. Паттерн core есть у кого-нибудь с протоколом? |
Цитата:
|
Цитата:
Ты спросил вопрос, тебе на него ответили, объяснили зачем так сделано. Тема закрыта. |
Давай я под итожу:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Будем ждать продолжения банкета. |
Цитата:
|
Цитата:
Сама админка написана давно. Она лишь версии меняет. |
builder'ы позволяют разбить создание запроса на несколько функций. Например, у меня все запросы создаются (build) в моделях, а в вызывающем коде:
m('user')->select(
['deleted' => FALSE,
'has_login_role' => TRUE,
'select_n_images' => TRUE,
...
'offset' => ...,
'limit' => ...,
'order by' => ...]);
ORM мне самому не нравятся. Обычно через непродолжительное время наступает момент "извините, но в данной ORM это не возможно". И код у них обычно сложный. Единственный "завершенный" вариант, который я видел - Entity Framework (MS). Но он статический, а мне это как минимум непривычно. Абстракция от БД - миф. При переходе на другую БД в любом случае надо будет просмотреть все запросы. Если ты не используешь Entity Framework. Цитата:
По поводу документации, в kohana ее наверное не очень много. Хотя сейчас наверное документации больше. Они по этому поводу сильно не парятся. Говорят, что чтобы использовать kohana нужно быть готовым заглядывать в исходный код. Код хороший и с комментариями. У меня проблем не было. И мне нравится эта позиция - отсеивает лишних кандидатов. Либо с другой стороны, учит нужных кандидатов. |
Цитата:
Основная была: Цитата:
|
Цитата:
p.s. по поводу производительности Цитата:
http://spb-borodin.livejournal.com/779.html |
Цитата:
В принципе я согласен что это не нужно, но и вреда от этого не много. Цитата:
Я вообще о БД как то не задумываюсь. Мне достаточно удобно с ней работать и всё. Может быть то что возникла такая тема говорит о том что ТС не удобно работать с БД в таком стиле в каком он сейчас это делает? ..... Цитата:
|
Цитата:
Другое дело, когда мы берем 40 дешевых и средних хостингов от разных компаний и вешаем на них какое-нибудь друпал или ещё что-то подобное и на 39 из них будут тормоза. Да если с сайтом не работать то тормозов не будет, но если начинаешь выращивать на таком хостинге проект из 50 человек в день на 10000 - 100000 и с ним ещё нужно работать через админку, то всё становится гораздо печальней. И первый вопль - бабла дай! На сервер, хостинг ... По поводу окупаемости да, хостинг легко окупится, а кто окупит программистов, операторов, фотографов и т.д. Идея разворачиваемости приложения за кратчайшие сроки хороша, но нужна не только идея быстроты разворачиваемости, но и схема затраты/скорость/расширяемость/окупаемость. И там где нужна скорость ООП и шаблонизаторы идет лесом. Как и по цитате выше. |
P.S.: я ещё не дорос до Highload
|
| Часовой пояс GMT +3, время: 21:49. |
|