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

C>>В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.
A>Хммм идея для меня новая, интересно. Правда боюсь опять будет информационный мусор в виде примитивов синхронизации, которых часто ожидают, но малый период времени (скажем ноль, Wait тут же возвратил управление).
A>В любом случае звучит первспективно. Захотелось добавить в .Net
Так блокировки с малым временем ожидания отфильтруются сами. Надо смотреть, на те блокировки, на которые образуется большая очередь ожидающих. Ну и потом сортировать их, например, по среднему времени ожидания или по количеству ожидающих.

Это все сценарии starvation'а, естественно, не покроет. Но мне оно помогло найти злобный лок, из-за которого весь сервер тормозил.

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

A>Типа того. BLT — вобщем кустарная штука. Hibernate — один из признанных промышленных реализаций. LINQ — этот интеграция языка запросов и всей инфраструктуры ORM в компилятор языка, что позволяет получить проверку запроса на этапе компиляции. Плюс Linq унифицирует доступ к разнородным провайдерам даннх, т.е. к СУБД, коллекциям,...

Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.

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

C>>А вообще — я бы не стал такой хак делать, а просто отдавал бы клиентам storageMap — нефиг скрывать такие детали доступа.
A>На то они и детали, чтоб скрывать.
Ты уж разберись — скрывать или нет

A>>>Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.
C>>Так этот объект — это ЧАСТЬ DAL.
A>Я думал, что User в данном случае BO.
Нет, это часть слоя доступа к данным У меня в объектах-сущностях нет никакой логики (за исключением тривиальных хелперов).

A>BO — часть DAL звучит как-то странно. BO возвращается DAL, но от DAL зависеть не должен.
А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.

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

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

A>>Типа того. BLT — вобщем кустарная штука. Hibernate — один из признанных промышленных реализаций. LINQ — этот интеграция языка запросов и всей инфраструктуры ORM в компилятор языка, что позволяет получить проверку запроса на этапе компиляции. Плюс Linq унифицирует доступ к разнородным провайдерам даннх, т.е. к СУБД, коллекциям,...
N>Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.
Нет. Максимум что видел: http://dtemplatelib.sourceforge.net/dtl_introduction.htm

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

C>У меня в объектах-сущностях нет никакой логики (за исключением тривиальных хелперов).

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

C>А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.

Есть архитектурная зависимость, скажем в XML-храниище карта будет не нужна. То есть поля класса User хранятся кучно торчит наружу слишком сильно.

C>Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.

Ну вот и я пишу дополнительный код, но в виде ХП.

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

A>Здравствуйте, Cyberax, Вы писали:
C>>У меня в объектах-сущностях нет никакой логики (за исключением тривиальных хелперов).
A>Ага, да, встречался уже. ХЗ, особенных преимуществ я в таком подходе не нашёл, недостатков тоже. создалось впечатление что это в большей степени дело вкуса.
Есть очень большое преимущество — код можно выделить в отдельную библиотеку, разделяемую разными проектами.

C>>А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.
A>Есть архитектурная зависимость, скажем в XML-храниище карта будет не нужна. То есть поля класса User хранятся кучно торчит наружу слишком сильно.
Для XML и другие структуры данных часто нужны. Так что это еще отдельный вопрос.

C>>Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.
A>Ну вот и я пишу дополнительный код, но в виде ХП.
Так ты его пишешь для ВСЕГО, а мне он только для некоторых "некрасивых" объектов нужен.

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

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

T>>Почему я и говорю, что модель данных предметной области != схема БД.

A>Правда, модель данных предметной области != иерархия классов. Суть же мысли в том, чтобы не играть в испорченный телефон при построении БД.

A>модель данных предметной области -> иерархия классов -> схема БД.

T>>К слову, упоминавшийся Hibernate позволяет реализовать наследование классов в БД по крайней мере тремя различными способами. Так же он позволяет указывать custom type mapping для полей класса, кроме того можно разнести разные поля класса по разным таблицам. Остается простор для оптимизации, но бизнес-логика от механизма хранения данных максимально абстрагируется. В 90% случаев этого достаточно, чтобы минимизировать несоответствие между тем как информация представлена в классах и как в БД. Если не удается хорошо представить предметную область в конкретном ЯП можно поискать другой более выразительный. Если кому-то удобнее работать с объектами предметной области с помощью SQL и ХП и это удовлетворяет всем требованиям к продукту, то ради бога. Но, что, касается меня, database-centric подход мне не нравится.

A>Hibernate как и любая ORM это обощённое средство. Оно ничего не знает о смысле данных, только о структуре.

A>Вот пример из реальной жизни:
A>Была табличка с пользователями Users
A>
A>
A>
A>
A>

ID	Login	Password	FirstName	LastName	DateOfBirth
1	admin	...	John	Doe	01/02/1972
2	user	...	Mary	Smith	03/04/1981

A>которую постоянно меняли. Когда это надоело переделали так
A>Users
A>
A>
A>
A>
A>

ID	Login	Password
1	admin	...
2	user	...

A>UserProperties
A>
A>
A>
A>
A>
A>
A>
A>
A>

ID	Name	Value
1	FirstName	John
1	LastName	Doe
1	DateOfBirth	01/02/1972
2	FirstName	Mary
2	LastName	Smith
2	DateOfBirth	03/04/1981

A>Таблицы с тех пор больше не перестраивались, наступило временное счастье.

Ха-ха, так в ряде случаев такая структура — известный анти-паттерн, есть даже для нее название, но я к сожалению не могу припомнить его. Структура запросов с джойнами, агрегатами настолько усложняется, что ну его нафиг. Для системы к которой предъявляются требования по выскокой производительности — такая денормализованная структура bad practice. Вот для CMS какой-нибудь — нормально, так сделано в Alfresco CMS (кстати тоже через Hibernate).

A>Чуть позже выяснилось, что для инициализации объекта теперь требуется не один запрос к БД, а [количество полей + 1]. Это естестенно. На практике пришлось от автоматического мапинга отказатся, руками выгребать все User Properties для которых совпадал ID и раскидывать значения по полям класса руками. Так быстрее.
A>Конечно данную задачу можно решить и по-другому: кешированием. Кеширование объектов User снизило бы нагрузку на БД, только это не решение, а скрытие проблемы, работающее иногда. Если кешируемые объекты часто меняются (запрашиваются только для редактирования, например, SELECT и UPDATE будет поровну), кеш только ухудшит производительность. Проблему UPDATE это тоже не решает. Одно сохранение объекта выливается в [количество полей + 1] запросов в транзакции, вместо одного.

Ага, гемморой

A>Подобные проблемы, я считаю разумным решать через ХП, скрывающие структуру БД. Пользователь БД не знает одна у него таблица хранит сущность (в данном случае User) или она разбросана по нескольким таблицам. Более того, при изменении переписывается ХП, но не тот, кто её использует. Переносить это выше, в DAL, не разумно так как у нас особенности структуры БД теперь светятся в двух разных местах (на SQL — схема, на Java/C#/C++ — запросы) на двух разных языках и это надо регулярно синхронизировать.

А я вот не согласен. О каком пользователе БД вы говорите? У меня бизнес-логика вообще не знает, повторяю ВООБЩЕ, об особенностях хранении объектов в базе, о запросах, это скрыто соответствующими классами DAL (в частности DAO) и маппингом который указывается декларативно! Какая длина поля в базе, в какую таблицу заносить и т.д. все это скрыто. Ваше решение привязывает вас к конкретному поставщику БД, а я свою программу могу использовать с MySQL, PostgreSQL (суперская вещь), Oracle и т.д. В 10% случаев надо что-то подкрутить в DAL и все. Вот не устроил меня MySQL в котором двуфазный коммит отсутствует, я с него переехал на постгре, и почти ничего подкручивать не надо.

A>Иногда, на простых данных ORM действительно выдают что-то близкое идеалу. Часто, на не очень сложных данных, ORM выдают что-то относительно приемлемое. Но стоит продумать схему БД как следует, чтобы это была действительно хорошая схема, а не тормоз или монолит и всё что нагенерировали ORM приходится выкидывать. Вот потому я и считаю, что действительно перспективным и правильным является отображать Relational в Object, а не наоборот как сейчас и поступают.

Up to you.

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

A>>>>Не-не, это всё заплатки и хаки лишь бы не писать руками DAL.
C>>>Так этот объект — это ЧАСТЬ DAL.
A>>Я думал, что User в данном случае BO.
C>Нет, это часть слоя доступа к данным У меня в объектах-сущностях нет никакой логики (за исключением тривиальных хелперов).

Тут бы я поспорил конечно, но спор будет терминологическим . Все же объекты Domain Model это равноправная часть бизнес-логики, ведь вы не можете в сервисных (бизнес) методах избавиться от того же User и пр. Т.е. по мне так бизнес-логика не только какие-то голые функции, но и передача информации, flow.

A>>BO — часть DAL звучит как-то странно. BO возвращается DAL, но от DAL зависеть не должен.
C>А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.

C>Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.

Можно избавиться от аннотаций и переписать на XML, тогда User станет с виду обычным POJO. И adontz уже не сможет придраться
Жаль hibernate, jpa не позволяют аннотировать интерфейсы как Entity, было б вообще идеально с точки зрения разделения ответственности, но это принципиальная проблема.

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

A>Подобные проблемы, я считаю разумным решать через ХП, скрывающие структуру БД.

ХП не лучший выбор в данном случае. Лучше такие вещи решать через view.

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

A>Ну вот изменилось ТЗ (добавилась/изменилась функциональность) и кто-то (скажем, Архитектор, хотя не суть) добавил. Вот хороший был пример с секретным вопросом для восстановления доступа. В моей схеме БД вообще не затрагивается, даже DAL может не затрагиватся если оперирует только с коллекцией Dictionary<string, string> Properties. А так, пришлось бы столбец добавлять.

И в чём проблема добавить ещё одно поле в таблицу?

Здравствуйте, adontz, Вы писали:
A>Ну вот изменилось ТЗ (добавилась/изменилась функциональность) и кто-то (скажем, Архитектор, хотя не суть) добавил. Вот хороший был пример с секретным вопросом для восстановления доступа. В моей схеме БД вообще не затрагивается, даже DAL может не затрагиватся если оперирует только с коллекцией Dictionary<string, string> Properties. А так, пришлось бы столбец добавлять.
Идея правильна, в реализации не уверен.
Я имел опыт с системами, построенными подобным образом. Традиционно считается, что схему данных менять тяжелее, чем сами данные.
Однако это далеко не всегда так; кроме того, "добавление колонок" далеко не всегда сводится только к полям в UI. Как только начнет появляться какая-то бизнес-логика вокруг этих полей, например foreign key или запросы по их содержимому, начинаются проблемы. Как на уровне БД так и на уровне маппинга. По сравнению с этими трудностями alter table add column покажется детским лепетом.

Здравствуйте, Cyberax, Вы писали:
C>В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.
Расскажи поподробнее — если мы такую штуку для дотнета напишем, можно будет по паре поршей купить

Здравствуйте, WolfHound, Вы писали:
A>>kuj думает, что T-SQL это императивный язык.
WH>Вобщето таки императивный.
Совершенно верно. Операторы T-SQL декларативны, но программы на нем — императивны. Потому что мы таки управляем состоянием базы, и четко задаем последовательность этих состояний.

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

kuj>>>Это в том числе и о тестировании синхронизации. В той мере, в которой ее вообще можно тестировать модульными тестами.
WH>>Интересно как ты будешь модульными тестами ловить deadlock, starvation, race condition итп?
kuj>Это не задача модульных тестов.
Выделеное твои слова?

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

N>Какие есть ORM для С++, пригодные для использования? В частности интересует поддерживающие sqlite.

Зачем ORM для C++? Добрался до буфера резалтсета, преобразовал его к нужной структуре и готово. ORM — это изобретение управляемых сред, потому что в них криво реализован прямой доступ к памяти.

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

S>Здравствуйте, Cyberax, Вы писали:
C>>В Java такое есть — недавно всю крутость ощутил. В .NET/C++ тоже ничего не мешает добавить.
S>Расскажи поподробнее — если мы такую штуку для дотнета напишем, можно будет по паре поршей купить
В это делается, как я понимаю, достаточно просто — инструментируем инструкцию monitorenter (захват лока) и некоторые методы класса Object (типа wait). В инструментации записываем в глобальную очередь точное (наносекундное) время перед входом в лок и после входа в лок.

Ну а потом эту очередь можно анализировать — определить сколько в какой момент на каждом локе было contender'ов, время ожидания и т.п.

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

A>>>BO — часть DAL звучит как-то странно. BO возвращается DAL, но от DAL зависеть не должен.
C>>А у нас нет зависимости UserProperties от DAL. Для клиентов класса методы setName/getName работают абсолютно прозрачно, а то что они используют для хранения внутреннюю карту — так это личное дело объекта.
C>>Ну и как я сказал — даже от этого можно избавится, но придется писать дополнительный код.
T>Можно избавиться от аннотаций и переписать на XML, тогда User станет с виду обычным POJO. И adontz уже не сможет придраться
Ну я так обычно и делаю. Не нравятся мне аннотации — код превращается в сплошную мешанину.

Здравствуйте, kuj, Вы писали:
kuj>А так примерно и получается. Зато BLL это именно BLL, который ничего о других слоях не знает и знать не хочет.
Это тупик. Мы сейчас находимся в таком, я в отчаянии бью челом об стену. Считаю подобную практику порочной, по крайней мере для языка читающих запросов.

A>>Постепенно приходим к осознанию необходимости Query object.

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

S>Это тупик. Мы сейчас находимся в таком, я в отчаянии бью челом об стену. Считаю подобную практику порочной, по крайней мере для языка читающих запросов.

Терпи, браток, скоро грянет линк.

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

S>Здравствуйте, kuj, Вы писали:
kuj>>А так примерно и получается. Зато BLL это именно BLL, который ничего о других слоях не знает и знать не хочет.
S>Это тупик. Мы сейчас находимся в таком, я в отчаянии бью челом об стену. Считаю подобную практику порочной, по крайней мере для языка читающих запросов.

Разъясните подробнее пожалуйста.

У нас сейчас уже два довольно крупных проекта и третий на подходе работают по такой схеме и пока никаких особых проблем не было.