Эээ... а нафига интернет-магазину БД :) ?

документация изучена от и до ;)

и прокатывает, это же не вся разметка страницы, а только маленький фрагмент, но цена будет браться именно из этого фрагмента

Документация о том как Яндекс специфически интерпретирует общий стандарт.

Разница небольшая - лишь приставка "от". Но хорошо отражает смысл.

Это РАЗНЫЕ сущности. РАЗНЫЕ. Всё.

То что это решает частную ситуацию - ничего не значит.

Ваши подходы очень часто проходят в опасной близости к клоакингу. Роботы то не мыслят. Случайно могут и обидеться :)

Но дело даже не в этом.

Допустим AggregateOffer нам пойдет за оффер. Опустим все отличия, все моменты.

Опустим что завтра может понадобится иначе. Допустим....

Вы решили задачу? Нет. Не решили.

У вас здесь захардкожена цена. Пусть и в виде диапазона. Завтра цена упала ниже минимума и что? Так что цену держим отдельно? Или всё-таки в карточке?)

Да и пофиг это всё.

Смысл в том, что мы не знаем что будет завтра. Картинку я уже прилагал)

И заведомо выбирать архитектуру которая неуниверсальна, и работает только за счет костыля? Гы. Отличный путь.

яндекс здесь совсем не причём - он товарные предложения только через товары и цены показывает ;)

это про гугл и в решении вообще нет костыля - это полностью универсальное решение

сущность одна цена продукта

Ну раз это одна сущность, то выведи мне цену в снипете яндекса без приставки "от".

ещё раз, для писателей, яндекс микроразметку товаров в сниппет не выводит

Допустим это так. И что? Сегодня он не выводит, но советует оформлять. Завтра будет выводить, и это будет поводом менять всю архитектуру? Так кто еще бабки из клиентов пылесосит?)

Архитектура. Должна быть. Универсальной.

Это главная претензия к "коробкам" - не универсально. Есть некоторый запас гибкости, но ограниченный, и при выходе за его пределы работать невозможно... Нет, все работают конечно. Ведь знают полтора движка, и пилят на любимом даже то что нельзя, ибо другого не знают. Но осознанно закладывать ограниченную архитектуру.... Уже зная где споткнешься.... Не может быть. А точно зная что это у тебя не будет работать.... Точно знаешь что оно будет. Но еще нет. И пишем под то что сейчас. Ведь завтра заказчик заплатит бабосик. Много. Ведь вчера такого требования не было да? Так что мы не виноваты да?))))

во-первых, не будет

гугл, скорей всего тоже завяжет с этим, останутся только гугл покупки

во-вторых, решение полностью универсальное и проходит валидацию как в яше так и в гоше

Вы эээ... на борту первый день что-ли ?

Никаких универсальных архитектур не бывает. Это рассказки для акционеров.

Любая архитектура - это ограничения, и чем больше аспектов она охватывает тем

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

чтобы не разрабатывать самому, если ваша задача идеально на чужое ложится.

Собственно лейбмотив топика был именно в этом, нет смысла делать что-то

никому ненужное и универсальное. Это попросту не нужно. Даже использовать

это эффективно невозможно. Если изменятся требования, то безусловно надо

будет провести РАБОТУ и что-то ПЕРЕДЕЛАТЬ.

О ужас... переделать что-то при изменении тз. Какая неожиданность :) ?

Вся разница в том, придется ли вам переделывать в "тонком" магазине МАЛО,

или в бесполезно толстом ОЧЕНЬ МНОГО. Безусловно в толстом магазине что-то

можно переделать путем нажатия кнопок в админке, однако как правило это

всё работает неоптимальным и не всегда ожидаемым образом. Так что лучше...

поправить в коде прям... ей богу. Да, квалификация для этого как-бы больше

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

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

именно после него появятся поиски по полям без индекса в гигабайтных базах

и прочее веселье. Дураков нельзя подпускать даже к админке.

Конечно, если вы дорожите проектом. Если вы обслуживаете клиентов по принципу

"чем дешевле, тем лучше", то это путь не для вас, вам наоборот нужен битрикс и

парочка дебилов к нему для того, чтобы потом с чистым сердцем переводить людей

на другие тарифы хостинга...

ЗЫ. А как вообще народ с ДДОСом борется ? Я что-то смотрю, имея пару десятков

тысяч наименований можно секунд по 5 страницы генерить.

Этож достаточно сотни атакующих, чтобы так этим делом сервак занять, что он

"лопнет" и при свободных внешних каналах. И никакой кеш не поможет, если

опрашивать разные урлы. Да даже 0.5с на страницу - это 120 атакующих в минуту,

которые устроят "веселье".

Вы просто отстали от современных реалий лет на 10.

Так то я тоже там был, но более-менее успешно перешел в современный мир разработки.

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

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

Но дело вообще не в этом.

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

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

Второй принцип (точнее группа) это SOLID. Этот кусок я даже расшифрую ибо 100% программистов проходят через неверное понимание этого принципа.

1 - Принцип единственной ответственности - говорит нам о том, что один класс (или файл, или набор функций, ООП необязателен, хоть принцип и из ООП) выполняет одну функцию. В частности важнейший шаблон (см. ниже) MVC является примером правильного решения этого принципа. Самый минимум это отделение HTML от логики. (Да, многие всё еще используют такую кашу). Естественно возникает желание отделить еще и SQL в отдельное место. И механизм взаимодействия с базой отделить. Да так, чтобы мы могли поменять его на работу с файлами, вместо базы, и не менять весь код магазина. Примерно так у нас получится зачаточный MVC. Тупой, жирный и все такое, но уже почти MVC.

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

3 - Принцип подстановки Барбары Лисков «объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.» Т.е. если мне не подходит поведение скажем класса отвечающего за работу базы данных. Скажем у меня выросли потребности, я решил сделать несколько серверов БД, допустим банальная схема где запись в базу идет на главный узел, а для чтения идут несколько серверов которые автоматом синхрониируются. Ну и мне нужно сделать разделение запросов на чтение и запись, и для чтения сделать балансировку. Я делаю новый класс, который наследуется от старого, и заменяю на него все вызовы (в конфиге сервис-локатора меняется имя класса и везде меняется где он нужен). При этом я не меняю логику обращения к моему классу. Все функции что были у родителя остаются неизменными. Я не могу например потребовать чтобы вместе с запросом мне передавали информацию о том является ли запрос на чтение или на запись. Если изначально не предусмотрел, то менять структуру, благо это тоже просто, но нельзя сделать так, чтобы для односерверной реализации такой параметр не передается, а для многосерверной передается. (Да, я у себя не предусмотрел, и не буду, ибо у меня есть другой класс, общий для всех, где это потом легко делается). Т.о. если у меня 300 разных сущностей (разные виды документов, всякие товары, юзеры, комментарии и т.п.), то нигде ничего не меняется. Только в одном месте.

4 - Принцип разделения интерфейса: Клиенты не должны зависеть от методов, которые они не используют. Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы клиенты маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться клиенты, которые этот метод не используют. Не "проще" а раздельно.

5 - Принцип инверсии зависимостей - не очень четко, но смысл в том, чтобы уменьшить взаимные зависимости разных частей. Одна из реализаций этого принципа это то что я писал выше - модули работающие с базой не завязаны на конкретную реализацию, и поэтому изменение в одном месте не требует изменений везде. Я меняю класс базы данных, и все остальные классы этого и не замечают поскольку завязаны на абстракции, а не на реализации.

Принцип MVC - типичный принцип используемый для сайтов. Смысл в том, что весь прикладной код бывает трех типов.

Модели - основной код со всей логикой. Описывают всякие сущности в проекте. Пользователи, товары, категории, страницы, платежные системы, адреса, заказы ит.п. - всё с чем мы работаем это модели. Модель хранит данные и имеет методы для манипуляции с ними. Например комментарий который пишет пользователь, чужие комментарии которые видны в списке, свои комментарии которые мы можем редактировать, комментарии которые видны в админке, комментарии которые ждут модерации - всё это комментарии, и если допустим мы сделаем у него... да пусть признак "автор является топикстартером" (допустим комментарий в форуме), то это свойство будет везде. И мы можем на его основе иначе отображать как пользователям, так и админам, иначе модерировать и т.п. Сразу и везде.

Представления (View) - код отвечающий за внешний вид. Обычно это не только шаблон а именно код, с ним связанный, но бывает логика представления лежит прямо в шаблоне. Возьмем к примеру категорию товара. В админке она выглядит и как строчка в таблице, и как форма с данными и как табличка со значениями. На сайте это красочная страница с кучей плюшек в которой и подкатегории и товары этой категории. А еще может быть у разных категорий совсем разное оформление. Но это одна категория, с одними свойствами, одними методами и т.п. (Модель). Просто выведена в разных представлениях. При этом представление может быть одно даже у разных моделей, например можно для раздела новостей использовать представление такое же как у раздела статей. Или еще момент - у меня есть превью для товара. У него есть картинка, название, текст, плашки новинок/бестселлеров, ссылка на категории, форма быстрого добавления товара в корзину и т.п. Они одинаковые что в разделе товаров производителя, что в поисках, что в списках товаров в категориях, что в списках товаров подкатегорий у "метакатегорий", что на главной в красивых листалках для топпродаж и т.п. Еще есть списки похожих, рекомендуемых товаров, "запчастей" и прочего. В типичном товаре таких мест с дюжину а то и больше. Если у этого блока хорошо с универсальностью, и есть настройки, например в категории мы выводим текст краткого описания а в списке акций на главной - нет и т.п., то мы можем сделать его лишь в одном месте. И если на вдруг нужно будет допустим изменить размер картинки, то мы поменяем его в одном месте, а не в дюжине.

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

Пример:

    public function updateAction() {
        $page =  $this->preparePage();
        // **********************************************************************
        $model = $this->model();
        // Пробуем обновить данные из POST, если обновили и данные валидны, то сохраним
        if(s()->post()->update($model) AND $model->isValid()) {
            $model->save();
            $this->redirect();
        } else {
            $page->model = $model;
            s()->layout()->show($page);
        }
    }

Например мы захотели вывести на странице куда будет переадресован пользователь сообщение о том, что объект который он редактировал - отредактировано.

Ок, не вопрос. Добавим одну строчку и получим:

    public function updateAction() {
        $page =  $this->preparePage();
        // **********************************************************************
        $model = $this->model();
        // Пробуем обновить данные из POST, если обновили и данные валидны, то сохраним
        if(s()->post()->update($model) AND $model->isValid()) {
            $model->save();
            s()->alert()->success($this->lang('updatedAlert'));
            $this->redirect();
        } else {
            $page->model = $model;
            s()->layout()->show($page);
        }
    }

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

Всё работает во всех админках, выводится и для редактирования страниц, и для товаров, и для пользователей. Для всего. Сейчас пока писал комментарий, так быстренько дописал, давно думал, но руки не доходили.

Даже не представляю как вы могли так умудрится. Совсем не представляю. У меня без оптимизаций, без половины индексов, без кеширования, без жадной загрузки и т.п., на сложных страницах выходит в пределах 0.25с. Нет, при сложных запросах статистики с сотнями тысяч записей или еще каких жирных местах - бывает и до двух секунд доходит, но это всё в админке, так что под ДДОС не пойдет.

А при чем тут урлы? Кешируют данные а не урлы, если пачка запросов будет одинаковая, то всё пойдет из кеша. Плюс кешируют не целую страницу а кусочки. Даже у разных страниц куча общих кусков есть. Нет кешируют конечно и целые страницы, и уже сформированный кусочек HTML, но там где это не поможет, там отрбатывает более низкоуровневое кеширование.

Таких мест где не кешируется ответ, да еще и полсекунды на ответ - мало. За ними приглядывают.

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

С другой стороны выдавать атаку в сотню IP давящих на слабое место - дорогое удовольствие. Допустим вы выдаете один запрос в 10 секунд. Чаще - забаню буквально со второго или третьего запроса. Тогда это 2000 одновременных IP чтобы держать 100 одновременных сессий. Такую пачку уведут в бан минут за пять. Слишком много сложных запросов на фоне отсутствия мелких... Нереально.

За час у вас улетит весь запас взломанных IP что у вас был). Но час никто держать атаку не будет. Допустим вы лупанули не сотню а тысячу одновременных сессий. Это уже чувствительно. Сервер "понимает" что идет атака, атака тяжелая, и антиДДоС выводит всем у кого нет куки что его проверили заглушку, которая пару секунд грузит клиентский комп, и только после этого проходит дальше. Допустим хеш какой-то генерит пруфовворк. Компы без браузера уже улетели. Компы которые зашли сразу в слабое место бьют - улетели. Те что остались - сильно греются).

В общем цена атаки вырастает до очень заметных сумм. А там уже более серьезная защита работает.

Но повторюсь - сайт который тратит полсекунды на какую-то страницу где нельзя серьезно закешироваться, и это доступно для неавторизованных пользователей - нонсенс.