Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, gandjustas, Вы писали:

G>>Ну это получится сервис в терминах anemic — класс содержащий логику обработки данных, и не содержащий самих данных.

ВВ>Это будет не сервис в каких бы то ни было терминах. Это будет класс, представляющий собой ту или иную вполне предметную абстракцию. Вместо Товар.ПолучитьСкидку() имеем сущности Товар и Скидка — и так далее.
Так он будет данные содержать или нет?

G>>А если детально проанализировать предметную область, то окажется что очень мало объектов на самом деле обладают поведением.

ВВ>Если в твоей предметной области мало объектов, которые обладают поведением, то значит жирная модель тебе не нужна. А вот в моей предметной области таких объектов много.
Пример? Какие персистентные объекты в твоей предметной области обладают плведением?

ВВ>>>>>А если организацию при создании параметризировать сервисом, вызов в который она будет делегировать для получения списка емплоееров?
G>>>>Это будет уже идиотизм. Так как сущности окажутся привязаны к сервисам без необходимости. А в остальном код такой же как в anemic будет.

ВВ>>>Вот когда придет понимание, что привязка сущностей к сервисам куда лучше лучше чем зависимость сервисов от контрактов сущностей — что противоречит даже большинству сервис-ориентед паттернов — тогда и станет понятно, чем хороша жирная модель.

G>>Давай в коде.
G>>ты предлагаешшь:

ВВ>Я предлагаю:
ВВ>- размещать в классах только ту логику, которая непосредственно завязана на эти классы, которая является, скажем так, сущностной характеристикой класса. Будет ли эта логика прописана непосредственно в методах класса или во внешнем классе — вообще без разницы.
Давай в коде. А то я совсем не представляю что такое "сущностная характеристика класса".

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

G>>В моем связность меньше. При этом еще код repository проще будет.
G>>Что не так?

ВВ>1. Код репозитория будет одинаков в обоих случах вообще-то
Нет. В твоем случае репозиторй занимается DI, для создаваемых объектов. Это далеко нетривиальный код.
В соем случае может быть использован generic-класс для репозитория. в 60 строк вместе с комментами (я такой и использую).

ВВ>2. Связности меньше между чем и чем? Ты серьезно считаешь, что заменив вполне логичное Организация.ПолучитьСотрудников на ПолучитьСотрудников(Организация) ты решил какую-то серьезную проблему?
Это тебя не туда занесло. Нету у меня такого как Организация.ПолучитьСотрудников на ПолучитьСотрудников(Организация). У меня есть возможность получить сотрудников вместе с организацией или полуить сотрудников для организации заданной ключом.

ВВ>Ну давай разберемся.
ВВ>Положим, у нас есть некий сервис, возвращающий сотрудников. Что еще делает этот сервис? Согласно каким принципам мы будем группировать функции в сервисы?
ВВ>Далее — этот сервис зависит от внешних метаданных. Что уже плохо само по себе. Если мы не хотим помимо этого получить еще и кучу внешних зависимостей от других сервисов — что уже совсем как-то странно — нам придется все-все-все, что хоть как-то связано с сотрудниками и организациями (а может быть еще и с ролями, и с департаментами и пр.) — запихать в один сервис. А приложение у нас — ну скажем, орг-структура. Т.е. фактически вся логика в одном сервисе. Ну нормально.
ВВ>Далее — нужно добавить новый метод — ПолучитьМенеджеров или что-то в этом роде, неважно. Что мы делаем? Дописываем новый метод в сервис? Ну это тоже совсем уж странно как-то. Умные люди говорят — надо новый сервис делать. Хорошо — новый так новый. Через неделю еще пару методов. Опять новый сервис?
ВВ>Пять лет наша система поработала. На что она похожа через пять лет? Правильно. Зажимаем нос, проходим дальше.

ВВ>И это банальный в общем-то пример. Орг-структура какая-то. А как быть с системами, в которых тысячи бизнес-сущностей. Вполне из жизни, кстати. Вот есть некоторая организация, которая собирает статистические данные — причем они у нее начинаются с уровня Государства и кончаются уровнем... Комната. Таким же макаром будем сервисы лепить?

ВВ>В итоге — мне честно уже неясно — а ради чего все это? Ну выделили логику в сервис, ну отлично, а дальше что? Делаем вид, что убрали зависимости. По-моему наоборот — потенциально зависимости усилили. И на кой этот сервис в таком виде-то? Нормальный паттерн — тот же СОА — на таких сервисах не построишь. Полиморфизм идет лесом. Так смысл?

Не туда тебя занесло. Не должна БЛ занимться получением связанных данных.
Это ты сам выдумал, а теперь сам же и опровеграешь.

Здравствуйте, gandjustas, Вы писали:
ВВ>>2. Связности меньше между чем и чем? Ты серьезно считаешь, что заменив вполне логичное Организация.ПолучитьСотрудников на ПолучитьСотрудников(Организация) ты решил какую-то серьезную проблему?
G>Это тебя не туда занесло. Нету у меня такого как Организация.ПолучитьСотрудников на ПолучитьСотрудников(Организация). У меня есть возможность получить сотрудников вместе с организацией или полуить сотрудников для организации заданной ключом.

Забыл уточнить. Это часть persistance инфраструктуры и к БЛ отношения не имеет.

Здравствуйте, gandjustas, Вы писали:

G>Что не так?

Твой код не компилиться .

Здравствуйте, gandjustas, Вы писали:

M>>В вашей ситуации, естественно, надо было выбирать исправление по обстоятельствам, что вы и сделали.
G>Ну так если весь код так писать он получится и быстрым и без огромного кеша.
Значит, LL в Linq2SQL придумали зря
Еще раз говорю, кеш огромен, потому что данных много.

G>>>Кстати как кеш обеспечивает когерентность в условиях работы нескольких приложений с одной базой (без общего кеша)? или просто при использовании ХП?
M>>Подмножеством методов, используемых в случае распределенного кеша: инвалидация кеша (полуавтоматическая, по таймауту или оповещениям с БД), маркировка областей кеша.
M>>В целом, при работе нескольких приложений (кластер как частный случай) с одной БД следует использовать общий распределенный кеш, чтобы не настраивать вручную параметры инвалидации кеша во избежание "заезда" в регион устаревших данных.
G>То есть предлагаете вместе с БД держать еще клатер для кеша? Очень круто.
Причем здесь кластер под кеш? В минимальном случае запускаете на машине сервис кеширования и все, хоть на той же, где БД, хоть на сервере приложений. Нужно 2 аппаратных узла -- запускаете на 2х машинах. Сервис кеширования в простейшем виде -- огромная распределенная хэш-таблица с автоматическим определением вышедших из строя узлов. В более сложном -- in-memory data grid с репликацией. Но кластер необязателен в любом случае.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Лобанов Игорь, Вы писали:

ЛИ>>>>В случае же, когда нас интересует только один аспект Работника, механизм lazy loading гарантирует нам, что "лишние" данные вообще не будут фигурировать в операции.

G>>>Очень наивно так полагать.

ЛИ>>Я всё же предлагаю разделять случаи, когда "должно, но не работает" и "в принципе не должно". Первое лечится багфиксингом, второе -- нет.

G>LL создает условия возникновения таких ошибок.

Жизнь вообще вредная штука, от неё умирают

Здравствуйте, meowth, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

M>>>В вашей ситуации, естественно, надо было выбирать исправление по обстоятельствам, что вы и сделали.
G>>Ну так если весь код так писать он получится и быстрым и без огромного кеша.
M>Значит, LL в Linq2SQL придумали зря
Не зря. Фреймворк должен давать все способы работы. А вот включили по-умолчанию зря.

M>Еще раз говорю, кеш огромен, потому что данных много.
Большое кол-во данных не означает что должен быть большим кеш.

G>>>>Кстати как кеш обеспечивает когерентность в условиях работы нескольких приложений с одной базой (без общего кеша)? или просто при использовании ХП?
M>>>Подмножеством методов, используемых в случае распределенного кеша: инвалидация кеша (полуавтоматическая, по таймауту или оповещениям с БД), маркировка областей кеша.
M>>>В целом, при работе нескольких приложений (кластер как частный случай) с одной БД следует использовать общий распределенный кеш, чтобы не настраивать вручную параметры инвалидации кеша во избежание "заезда" в регион устаревших данных.
G>>То есть предлагаете вместе с БД держать еще клатер для кеша? Очень круто.
M>Причем здесь кластер под кеш? В минимальном случае запускаете на машине сервис кеширования и все, хоть на той же, где БД, хоть на сервере приложений. Нужно 2 аппаратных узла -- запускаете на 2х машинах. Сервис кеширования в простейшем виде -- огромная распределенная хэш-таблица с автоматическим определением вышедших из строя узлов. В более сложном -- in-memory data grid с репликацией. Но кластер необязателен в любом случае.
Я знаю как системы кеширования запускать. Вопрос не в этом.
Вопрос в том что фактически вместе с базой еще надо и навороченный кеш держать, чтобы rich мог работать на большом количестве данных.

Здравствуйте, gandjustas, Вы писали:

G>Я его читал. Я предлагаю не рассматривать"предметную область" как вещь в себе.
G>Ведь в конченом итоге надо сделать приложение, которое полезно людям, а не модель некоторой предметной области.

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

S>>Ещё такое ощущение, что у вас разработка заканчивается с впариванием результатов заказчику — там такой подход конеш рулит.
G>Не совсем "впариваением", но смысл именно такой — чтобы заказчик был доволен.

А.. Ну здесь уже начинается сложная философская беседа о том как кого сделать довольным. У нас всё проще: заплатили деньги -> ???-> классный товар. Потому что поддерживать сможем только мы. А себя обламывать не хочется. Я ведь угадал нечаянно — у нас разные в принципе подходы к разработке ПО. И то что я тут вам пропагандирую, для вас никакой ценности не имеет. В итоге пора закругляться, на всякий отвечу на остальное.

---

G>Это зависит от закачика и от менеджера.
...
Ну да. И ни одна методика не будет работать с другими людьми. Потому что человек, которому абсолютно ничего не надо — самая вредная вещь в команде.

S>>Скажите, как вообще можно строить дизайн системы на основе функциональных требований?
G>Рецепты давно известны: слабая связность и следовать принципам KISS и YAGNI.
Дык это противоположность — мы пытаемся ослабить влияние дизайна на поддерживаемость программы. Вместо того чтобы "сидеть и наслаждаться", мы предпринимаем кучу усилий чтобы исправить свои прошлые ошибки.

Слабая связность рулит , но когда KISS и YAGNI понимают как "потом сделаю"... Не будет этого потом. Если нужно сделать что-то качественно — это надо делать сразу, с углублением в контекст и т.п. Куча мелких серий "час лепим одно, час-другое, потом возвращаемся" отвратительно влияет на код из-за банального выноса стека в мозге. Это тоже всё как бы общеизвестно...

S>>Они же описывают только внешний интерфейс системы. Всё что вы можете сделать — провести кластеризацию графа зависимостей и выделить компоненты по степени связности. Этот дизайн нифига не будет стабильным — любое новое требование перекроит все зависимости и дизайн, заточенный под конкретный набор юз-кейзов будет только мешать развивать систему.
G>Далеко не так. Ведь у нас есть не только пожелания заказчика, а есть еще и требования от предметной области.
G>Стартовый набор требований обычно достаточно большой, чтобы большая часть системы оставалась стабильной при всех изменениях.
Ну да. Вы сейчас сказали то что я от вас всю эту беседу добивался. Остался один логический шаг — информацию о предметной области можно использовать не только для дизайна, но и в обсуждениях функционала программы etc. Ну и естественно надо отделить объективную информацию от субъективных требований заказчика.

G>Угу Ubiquitous Language, проходили уже. А толку от него? Ну поговорили вы со специалистами на их языке, сделали требования корректныим.
G>Как это на дизайн приложения повлияет.

А тут два варианта — либо я вам щас проповедь закачу, либо скажу что влияет на стиль мышления: минимум терминов, всем в команде всё понятно (раздражает когда где-то в середине разработки выясняется что никто в предметной области не рубит), наличие одной модели позволяет выловить её косяки/косяки в требованиях. Обсуждать всё проще на порядок. Причём польза и заказчику — люди с таким удивлением обнаруживаю что у них бардак, так радуются что нашли где косяки, что аж приятно становится

Самая главная фича — изначально видны требования к структуре данных, и примерно видны правила по которым будет работать логика приложения. Фундамент есть с самого начала. Причём даром, т.е. практически безвозмездно(с).

S>>Ну и в подарок получаете дизайн устойчивый к самым неожиданным требованиям.
G>Если бы все было так хорошо, как на словах, то все бы давно использовали DDD.
G>Вот только DDD начинает отсасывать даже тогда, когда просто требуется добавить нетривиальную экранную форму для каких-либо целей.

А вы не путайте идею и то как Эванс её трактует. Он во второй части книги ни разу не следует самому себе — громадный репозитарий со всеми зависимостями и логикой там же. Это ж полный убиццаобстену. Но если включить мозги (с) ваше.

G>Вот становится весело, когда новые требования не укладываются в модель.
G>Например была какая-то банальная торговая система, а тут потребовалось внести возможность резервирования и предзаказа.

Гммм... в банальной торговой системе с самого начала известно что это ERM. Тут те фичи, что вы написали — как раз очевидные требования. Но да, бывает весело. Зато затронут изменения только ту часть системы что работает с товаром — слабая связность получается почти искаробки.

Спасибо, было очень приятно пообщаться

Здравствуйте, meowth, Вы писали:

M>Давайте я поясню, что ли по двум этим вопросам. Мне кажется, я понял, что вы хотите уточнить. Вы опасаетесь, что rich тянет много из БД -- вместо отдельных полей подтягивает весь объект и т.д. Такое в целом имеет место быть -- при использовании rich запросы получаются тяжелее (тянут больше данных), но на практике опасения не оправдываются по следующим причинам:
M>0) выборка 2х полей осуществляется практически с той же скоростью, что и выборка 20 (проверено на практике);
Это какая-то очень-очень нестандартная практика. Систематическое тестирование различных сценариев доступа к данным показывает, что себестоимость запросов очень сильно зависит от набора полей в выбранной проекции. Если это не так — то скорее всего у вас боттлнек где-то еще. Либо, что тоже возможно, на базу ни разу не смотрел вменяемый DBA. Например, в таблицах нет индексов (кроме тех, которые автоматически сгенерил ORM).
M>1) за счет объектного кеша такие запросы становятся крайне редки, потому что все данные уже тут;
Объектный кэш не уменьшает количество запросов. Он просто позволяет вам некоторое время делать вид, что их нету. Например, провоцируя замену нормальных декларативных способов описания связей объектов прямыми ссылками — чтобы можно было пользоваться навигацией вместо запросов. Что масштабируется хуже, чем SQL.

M>2) правильно настроенный LL и прочая инфраструктура позволяет минимизировать обращения к БД;
LL не может помочь минимизировать обращения к БД. Всё, что он делает — оттягивает момент неизбежного обращения к БД насколько возможно. Минимизация обращений возможна только при eager load, который за 1 обращение достаёт все нужные данные сразу.

M>Как-то так.

Здравствуйте, meowth, Вы писали:

M>Ой, какие нехорошие кеши, путаются все время
M>У меня кластер из серверов приложений, ничего не путаются. Наверное, потому, что shared cache, как делают все разработчики, использующие фермы.
Это всё замечательно. Вот только если бы вы выкинули нахрен ваш кэш, и развернули бы на том же железе чистое stateless-приложение с анемичной моделью поверх RDBMS, то совершенно на ровном месте получили бы рост throughput если не на порядок, то на полпорядка точно.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Я его читал. Я предлагаю не рассматривать"предметную область" как вещь в себе.
G>>Ведь в конченом итоге надо сделать приложение, которое полезно людям, а не модель некоторой предметной области.

S>Гммм... а тогда с чем вы не согласны? Эванс всё классно расписал про место предметной области. Это ничуть не новая идея, и ни разу не панацея. Эванс просто неплохой популяризатор, да и время удачно совпало.

Не согласен с тем что такой подход стоит применять при дизайне программы. Он хорош для анализа, не более того.


S>>>Скажите, как вообще можно строить дизайн системы на основе функциональных требований?
G>>Рецепты давно известны: слабая связность и следовать принципам KISS и YAGNI.
S>Дык это противоположность — мы пытаемся ослабить влияние дизайна на поддерживаемость программы. Вместо того чтобы "сидеть и наслаждаться", мы предпринимаем кучу усилий чтобы исправить свои прошлые ошибки.
И каким образом вы его пытаетесь ослабить? Написав больше кода? Не поможет. Чем больше кода, тем сложнее вносить изменения.

S>Слабая связность рулит , но когда KISS и YAGNI понимают как "потом сделаю"... Не будет этого потом.
Нет. YAGNI нужно понимать буквально: "это сейчас не нужно". А KISS означает что все что делается нужно делать наиболее простым способом.

S>>>Они же описывают только внешний интерфейс системы. Всё что вы можете сделать — провести кластеризацию графа зависимостей и выделить компоненты по степени связности. Этот дизайн нифига не будет стабильным — любое новое требование перекроит все зависимости и дизайн, заточенный под конкретный набор юз-кейзов будет только мешать развивать систему.
G>>Далеко не так. Ведь у нас есть не только пожелания заказчика, а есть еще и требования от предметной области.
G>>Стартовый набор требований обычно достаточно большой, чтобы большая часть системы оставалась стабильной при всех изменениях.
S>Ну да. Вы сейчас сказали то что я от вас всю эту беседу добивался. Остался один логический шаг — информацию о предметной области можно использовать не только для дизайна, но и в обсуждениях функционала программы etc. Ну и естественно надо отделить объективную информацию от субъективных требований заказчика.
Для функционала программи пофиг откуда требования.

G>>Угу Ubiquitous Language, проходили уже. А толку от него? Ну поговорили вы со специалистами на их языке, сделали требования корректныим.
G>>Как это на дизайн приложения повлияет.

S>А тут два варианта — либо я вам щас проповедь закачу, либо скажу что влияет на стиль мышления: минимум терминов, всем в команде всё понятно (раздражает когда где-то в середине разработки выясняется что никто в предметной области не рубит), наличие одной модели позволяет выловить её косяки/косяки в требованиях. Обсуждать всё проще на порядок. Причём польза и заказчику — люди с таким удивлением обнаруживаю что у них бардак, так радуются что нашли где косяки, что аж приятно становится
Это все относится к анализу требований. Совершенно не следует эти знания явно выражать в коде в виде объектов.

S>Самая главная фича — изначально видны требования к структуре данных, и примерно видны правила по которым будет работать логика приложения. Фундамент есть с самого начала. Причём даром, т.е. практически безвозмездно(с).
Это как раз плохо. Структура данных должна соответствовать функционалу системы, а не быть вещью в себе.
Надавно в соседней теме кто-то хотел иметь структуру дерева в БЛ, со всеми древесными операциями. Я расписал какие функции от этого дерева потребуются на примере иерархического форума. Оказалось что обобщенное дерево совершенно не нужно.

Здравствуйте, meowth, Вы писали:
G>>Не выдумывай. Я не написал что мешают все средства, мешают только некоторые, такие как LL например.
M>В другом посте вы сказали, что для anemic тоже есть инфраструктура, обеспечивающая persistence ignorance. LL -- это ее важная часть. А тут вдруг оказывается, что LL -- мешает. Интересная у вас логика. Об ее "жестокуюю реальность" "разбивается" моя точка зрения )
Еще раз: не надо путать похожие вещи. LL — это важная часть ignorant persistence, а не persistence ignorance.

Здравствуйте, gandjustas

Я ж говорю — у нас разная ситуация, поэтому спорить бессмысленно. Я кучу раз приводил по пунктам что даёт модель предметной области. Вы всё это отметаете одним "это не нужно". Ну напишу я ещё раз, вы ещё раз скажете что всё неверно... Изменится что-нить?

Завязываю.

Здравствуйте, Sinclair, Вы писали:

S>LL не может помочь минимизировать обращения к БД. Всё, что он делает — оттягивает момент неизбежного обращения к БД насколько возможно. Минимизация обращений возможна только при eager load, который за 1 обращение достаёт все нужные данные сразу.

1 обращение не всегда хорошо. Может оказаться, что одна часть выборки очень хорошо кешируется — зачем тогда её каждый раз выбирать запросом, лишний раз нагружать СУБД? А в случае LL достаточно навесить кеширование на связанную сущность — и она выберется лишь один раз, дальше будет так же по одной выборке.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, meowth, Вы писали:

M>>Ой, какие нехорошие кеши, путаются все время
M>>У меня кластер из серверов приложений, ничего не путаются. Наверное, потому, что shared cache, как делают все разработчики, использующие фермы.
S>Это всё замечательно. Вот только если бы вы выкинули нахрен ваш кэш, и развернули бы на том же железе чистое stateless-приложение с анемичной моделью поверх RDBMS, то совершенно на ровном месте получили бы рост throughput если не на порядок, то на полпорядка точно.

Ух ты, еще один анимист-экстрасенс А диагноз по фотографии вы не ставите?

Не обижайтесь +) Сколько у вас MsSQL транзакций в секунду делает, если не секрет? Ну так, чтобы thru-put соизмерить.
ИМХО если не будет кеша, однозначно растет количество запросов в БД, которая является слабым местом системы. Stateless или statefull -- это уже другой вопрос.

Здравствуйте, Sinclair, Вы писали:

S>Это всё замечательно. Вот только если бы вы выкинули нахрен ваш кэш, и развернули бы на том же железе чистое stateless-приложение с анемичной моделью поверх RDBMS, то совершенно на ровном месте получили бы рост throughput если не на порядок, то на полпорядка точно.

Вот мы сначала так и сделали. Оказалось, что кешировать редко изменяемые сущности и запросы очень выгодно.

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

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas

S>Я ж говорю — у нас разная ситуация, поэтому спорить бессмысленно. Я кучу раз приводил по пунктам что даёт модель предметной области. Вы всё это отметаете одним "это не нужно". Ну напишу я ещё раз, вы ещё раз скажете что всё неверно... Изменится что-нить?
Так это действительно не нужно.
Преимущества, описываемые вам — мнительные. Хорошее приложение можно и без них написать.

Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, Sinclair, Вы писали:

S>>LL не может помочь минимизировать обращения к БД. Всё, что он делает — оттягивает момент неизбежного обращения к БД насколько возможно. Минимизация обращений возможна только при eager load, который за 1 обращение достаёт все нужные данные сразу.

WF>1 обращение не всегда хорошо. Может оказаться, что одна часть выборки очень хорошо кешируется — зачем тогда её каждый раз выбирать запросом, лишний раз нагружать СУБД? А в случае LL достаточно навесить кеширование на связанную сущность — и она выберется лишь один раз, дальше будет так же по одной выборке.

Такое работает только для справочных данных. Их вообще можно кешировать на клиенте.

Здравствуйте, meowth, Вы писали:

M>ИМХО если не будет кеша, однозначно растет количество запросов в БД, которая является слабым местом системы.
БД является слабым местом если приложение неэффективно работает с ней. Синклер говорит (имхо небезосновательно) что можно написать приложение так, что вы будете не состоянии одинм аппсервером закормить БД, и не применять при этом распределенный кеш с кешированием результатов запросов.

Здравствуйте, Sinclair, Вы писали:

M>>0) выборка 2х полей осуществляется практически с той же скоростью, что и выборка 20 (проверено на практике);
S>Это какая-то очень-очень нестандартная практика. Систематическое тестирование различных сценариев доступа к данным показывает, что себестоимость запросов очень сильно зависит от набора полей в выбранной проекции. Если это не так — то скорее всего у вас боттлнек где-то еще. Либо, что тоже возможно, на базу ни разу не смотрел вменяемый DBA. Например, в таблицах нет индексов (кроме тех, которые автоматически сгенерил ORM).
M>>1) за счет объектного кеша такие запросы становятся крайне редки, потому что все данные уже тут;
S>Объектный кэш не уменьшает количество запросов. Он просто позволяет вам некоторое время делать вид, что их нету. Например, провоцируя замену нормальных декларативных способов описания связей объектов прямыми ссылками — чтобы можно было пользоваться навигацией вместо запросов.
S>Что масштабируется хуже, чем SQL.

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

M>>2) правильно настроенный LL и прочая инфраструктура позволяет минимизировать обращения к БД;
S>LL не может помочь минимизировать обращения к БД. Всё, что он делает — оттягивает момент неизбежного обращения к БД насколько возможно. Минимизация обращений возможна только при eager load, который за 1 обращение достаёт все нужные данные сразу.
ИМХО вы меня не поняли. Там была жалоба на то, что LL увеличивает количество обращений к БД до неприличного в случае коллекций. А я говорил, что правильно настроенный lazy load может вытягивать эту коллекцию batch-ем -- скажем, 30 айтемов за 3 раза, а кроме того -- брать ее из кеша.

Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, Sinclair, Вы писали:

S>>Это всё замечательно. Вот только если бы вы выкинули нахрен ваш кэш, и развернули бы на том же железе чистое stateless-приложение с анемичной моделью поверх RDBMS, то совершенно на ровном месте получили бы рост throughput если не на порядок, то на полпорядка точно.

WF>Вот мы сначала так и сделали. Оказалось, что кешировать редко изменяемые сущности и запросы очень выгодно.

WF>Да и вообше, практически все, кто пишет о высоких нагрузках, большое значение уделяют именно кешам.
Кеширование разным бывает.