ООП головного мозга

[micscr]

Хватит засирать мою тему

А что не так с твоей темой?
Ты спросил вопрос, тебе на него ответили, объяснили зачем так сделано. Тема закрыта.

[Gozar]

Давай я под итожу:

может быть сложней кодинга с нуля.

те кто научились так настраивать - они понимают. Этому надо учиться и немало.

Старые наработки уже не пашут.

Раз в 2 года они меняют апи, и надо переучиваться.

Старые наработки уже не пашут.

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

Раз в 2 года они меняют апи, и надо переучиваться.

Старые наработки уже не пашут.

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

Будем ждать продолжения банкета.

[Tim]

Мухаха. Выпили из друпала.

Сказал человек и продолжил пилить свой велосипед который далеко не фак что будет лучше друпала.

[Gozar]

велосипед который далеко не фак что будет лучше друпала.

Он уже гораздо лучше друпала. Он прост в понимании и там есть всё для программистов. Хош крути модули, хош вставляй свой код, для него отдельные файлики есть, апдейты ничего не поломают. Осталось сделать пару сборок для пользователей и чуть доработать ядро, наштамповать шаблонов и вуаля.

Сама админка написана давно. Она лишь версии меняет.

[x-yuri]

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.

Такие реализации только добавляют ненужные тормоза в программу.

Тебе не нужен ORM/builder'ы или ты так думаешь. Зачем приплетать к этому какие-то тормоза? Я в свою очередь мог бы сказать: "Мой ООП код так же тормозит как твой процедурный код". Не важно, что при 1000000 тысячах итераций ООП-страничка отобразится медленнее, чем процедурная страничка. Важен компромисс между удобством разработки, скоростью разработки и производительностью. Ведь цель - создать сайт, а не абстрактно ускорить сайт, м? Но можем попробовать написать небольшой сайт, ты на своем фреймворке, я на kohana. Сравним... В прицнипе есть еще php fat-free framework, но тогда скорее всего в моем коде будет недостаточно ООП.

По поводу документации, в kohana ее наверное не очень много. Хотя сейчас наверное документации больше. Они по этому поводу сильно не парятся. Говорят, что чтобы использовать kohana нужно быть готовым заглядывать в исходный код. Код хороший и с комментариями. У меня проблем не было. И мне нравится эта позиция - отсеивает лишних кандидатов. Либо с другой стороны, учит нужных кандидатов.

[Gozar]

Зачем приплетать к этому какие-то тормоза?

Это была не главная мысль, а лишь следствие. Можно было не акцентировать на этом внимание.

Основная была:

Абстракция от БД - миф

[x-yuri]

Это была не главная мысль

ну я все равно немного дополню, для полноты картины. Мне самому не нравится Zend и java/c# мне кажутся излишне сложными. Но может им так лучше... Важно адекватно выбирать инструменты: не нужно - не используй, нужно - используй.

p.s. по поводу производительности

[5] Highload и архитектура крупного проекта - это особый вид решения задачи. Это вообще не программирование, в традиционном понимании. Например, забудьте, что вы эксперт по EXPLAIN. Он вам практически никогда не понадобится, т.к. в хайлоде применяются только примитивные запросы, типа SELECT по primary key. Много вещей, знанием и опытом которых вы гордитесь, как гуру программирования - не нужны! Голова - да, нужна.

Необходимо думать на этапе проектирования о важных вопросах. И не нужно - о несущественных вопросах: какой язык программирования выбрать, какую базу данных. Особо глупый вопрос - какой фреймворк выбрать, например, на PHP их десятки (доказательства - позже). Так же неважно, какую базу данных выбрать, т.к. мы будем использовать 1% ее возможностей, примитивные SELECT/UPDATE. Уважаемые авторы MySQL и PostgreSQL чуть ли не дерутся за графики мультитредовой производительности на всяких конференциях DevConf и Highload++, только забывают мелочь - в хайлоде это не интересно (т.е. не самое важное). Ну, нет у нас сложных запросов или критических нагрузок на один инстанс.

Первые шаги на правильном пути - осознать несущественность этих вопросов и спроектировать каждый из компонентов проекта горизонтально масштабируемым. Сложно объяснить, что именно делать. Зато легко показать, каким глупостям не нужно уделять внимание. Относительно выбора между MySQL и PostgreSQL: наша задача сделать так, чтобы ни на одном SQL инстансе, какой бы общей нагрузка ни была, не случился затык по производительности. Мы просто покупаем новый сервер и нагрузка сама перетекает туда. Вы достигли этого состояния? Тогда смело плюйте на графики производительности, вы - выше этого!

http://spb-borodin.livejournal.com/596.html
http://spb-borodin.livejournal.com/779.html

[Tim]

Абстракция от БД - миф

Ну и отлично. А где тормоза? Лишние классы для не нужных БД просто не подключатся и всё.
В принципе я согласен что это не нужно, но и вреда от этого не много.

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

Я вообще о БД как то не задумываюсь. Мне достаточно удобно с ней работать и всё. Может быть то что возникла такая тема говорит о том что ТС не удобно работать с БД в таком стиле в каком он сейчас это делает? .....

Хватит засирать мою тему

Извини. Просто она не очень интересна. Я реально не думаю о том как я работаю с БД.

[Gozar]

p.s. по поводу производительности

По поводу своего сервера(ров) и горизонтальной масштабируемости понятно.

Другое дело, когда мы берем 40 дешевых и средних хостингов от разных компаний и вешаем на них какое-нибудь друпал или ещё что-то подобное и на 39 из них будут тормоза.

Да если с сайтом не работать то тормозов не будет, но если начинаешь выращивать на таком хостинге проект из 50 человек в день на 10000 - 100000 и с ним ещё нужно работать через админку, то всё становится гораздо печальней.

И первый вопль - бабла дай! На сервер, хостинг ...

По поводу окупаемости да, хостинг легко окупится, а кто окупит программистов, операторов, фотографов и т.д.

Идея разворачиваемости приложения за кратчайшие сроки хороша, но нужна не только идея быстроты разворачиваемости, но и схема затраты/скорость/расширяемость/окупаемость. И там где нужна скорость ООП и шаблонизаторы идет лесом. Как и по цитате выше.

[Tim]

P.S.: я ещё не дорос до Highload