ORM vs Linq and BLToolkit :) - Философия программирования

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

D_A>Не стоит забывать про полезности ОРМ

Полезный выхлоп у ORM безусловно есть. Иначе бы им вообще никто не пользовался. Вопрос в том, что перевешивает.

D_A>- вычитка и сохранение графа объектов (уж если есть в системе визард, то в сессии можна держать этот граф);

Зачем?

D_A>- поддержка транзакций в моделях;

Stateful? Зачем?

D_A>- контроль изменения свойств объектов (облегчается апдэйт);

Это всё делается и без ORM.

D_A>- кэширование параметров СП;

ORM тут тоже не при чём.

D_A>- а самое главное — объект запроса в ОРМ — это класс

В BLToolkit ExecuteList и ExecuteObject тоже возвращают объекты. Причём какие хочешь объекты, без всяких искуственных ограничений типа прибитых гвоздями базовых классов от ORM. Это делается с помощью простейших мапперов и функций хелперов.

D_A>, который можна ПРОТОТИПИРОВАТЬ — держать в сборке бизнес логики, в этом вся фишка — конрол фильтра на ГУИ всего лишь компонирует результирующий запрос из прототипов. Пртототипов не так уж и много, значит и множество результирующих запросов в законченном приложении есть конечно, а значит прекрасно кэшируются эти же запросы на сервере БД при выполнении. Тоже самое с сортировкой. Следовательно, очень большая часть рутины, тоесть ее реализайия — вполне обходимся ОРМ.

Фильтрация и сортировка, особенно во втором фреймворке делается штатными средствами как два байта.

D_A>Минус — в каждом готовом ОРМ есть то. чего как-раз не хватает, особенно это относится к архитектуре самой модели и фабрик. Почему фабрик — чтобы варьировать реализацию модели — подставить свою. Просто не всегда умеют проектировать правильно

.

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

D_A>Вот мы писали аукцион. Есть админ зона и паблик. Так из всего, что надо было выполнить, всего лишь часть, отвечающая за подгрузку состояния бида в риалтайме — это реализовывальсь просто хранимым кодом, все остальное — чистый ОРМ, а скорость разработки была отличной.

D_A>Только ОРМ!!!

Хочешь посоревноваться?

IT>>А мапер из них можно выдернуть? Что если у меня источник XML, comma delimitted поток или объектная модель соседа?

D_A>Use BizTalk server

Да, это как раз то, что надо. $25k на процессор за переливание из пустого в порожнее.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>И кстати, не забывай. BLToolkit точно такая же ORM как и другие. Просто сильно недоделанная. Она делает абсолютно то же самое что и другие. Просто и типовых шаблонов как таковых раз-два и обчелся, поэтому ест тенденция работы прямыми вызовами, и дополнительных инструментов мало.

BLToolkit — это не ORM, это DataAccess + Mapper. Вещи независимые, которые вполне могут использоваться отдельно. Делать из этих заготовок свою собственную ORM или не делать — это уже дело разработчика. У меня, например, ни на одном проекте не получалось на 100% использовать одну и туже схему. На каждом проекте что-то своё. Как правило для WebForms и WinForms модели получаются совершенно разные. Где-то нужен глобальный кешь, где-то локальный, где-то pure stateless. Каждый раз я подстраиваю BLToolkit под задачу. В случае с ORM всё наоборот. Я вынужден задачу подстраивать под ORM.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Современный ORM это значительно более сложная вещь.
Это мы запишем в минус современным ORM..

GZ>И не ограничевается CRUD.
А где там хоть слово, про то что их ORM ограничивался CRUD? Наоборот, был весьма навороченой конструкцией...

GZ>Основная его проблема в том, что он вместо того чтобы взять готовый ORM где уже проффесионально решены все эти проблемы, он решал их сам.
Мужик, это был 98й год, какие готовые ORM?

GZ> К тому же, абсолютно прозрачный ORM — это гадость, поскольку подразумевает чистый Lazy Load. За такое убивать надо. Современный ORM — это не только CRUD.
Ты не понял, подвох в том, что ребята налабали афигительный ORM, который решал практически все проблемы работы с данными исключительно объектным способом... Pure OO nirvana. А оказалось, что все эти навороты нафиг не нужны, потому как слишком много "special cases", которые все равно надо обрабатывать в ручную..

GZ>2.1 Мы отдаем это stored procedure, пускай он транслирует его в физ. термины и обрабатывает. Это значительно лучше чем п.1 но проблематичен. Во первых логика связи между реляционной и объектной схемой весьма сложна.
Ничего сложного...

GZ> Во вторых сложно делать парсинг запроса в T-SQL.
Зачем?

GZ> В третьих мне придется также делать то же самое на PL/SQL.
Не придется. Я не верю в много БД-шные проекты, по крайней мере в те, где все это делает один человек.

GZ>2.2 Берем ORM(не важно DLinq или Hibernate) и строим запрос по логической схеме. Пускай он думает как сгенерить SQL в физических терминах. Его неглупые люди писали.
Какие-бы неглупые люди не были, они не могли предумотреть всех частных случаев, о чем и пишет Вастерс, а частных случаев, на практике, оказывается лишком много.

GZ>Языки для XLinq, DLinq и Linq похожи но переносимы ли они?
Ха, переносимы.. Я могу в одном выражении получить объект через DLinq, отфильтровать с помощю Linq и выдать результат через XLinq...

... [RSDN@Home 1.2.0 alpha rev. 619]

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

GZ>LINQ и DLINQ — похожие вещи но с разными целями. Я вообще плохо понимаю зачем нужен LINQ. Только разве что для организации локального хранилища объектов. Я очень сомневаюсь что кому-то надо трансформить логическую модель. Сейчас разговор о DLinq. А он как раз и есть ORM.

Принципиальное различие в том, что ORM скрывает от разработчика детали работы с БД. Точнее пытается скрыть, но делает это не всегда хорошо. Лично мне, как разработчику, понимающему что такое БД, этого, спасибо, не надо. Я даже считаю это вредным. Я хочу чтобы мне помогали, а не думали за меня. Если мне нужен сложный запрос к БД, то я хочу быть на 100% уверен в том, что он максимально эффективен и отлажен, я хочу посмотреть план и убедиться, что лишних ресурсов этот запрос не потребляет. Никакому ORM в этом случае я доверять не могу. Точнее скажем так. Я недостаточно уверен в том, что способен нарисовать такую объектную модель, которую подхватить ORM и эффективно отобразит её на реляционную структуру.

А маппинг — это дело десятое, это вообще перекладывание из пустого в порожнее. BLToolkit умеет перекладывать что попало во что угодно. БД лишь частный случай. В этом принципиальное отличие от ORM.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Не-а.
Зря..

GZ>1. В большинстве случаев для запросов хватает стандартного Array,Find с делегатом. Благо запросы в большинстве своем, работают по одной коллекции.
Это тебе сейчас хватает, а вот дадут тебе Linq и не поймешь ты как раньше без него жил..

GZ>2. Запрос будет неудачен, если коллекция не подгружена.
Не надо там ничего грузить, и так хорошо.

GZ>Есть в принципе один вариант использования.
Да их там вагон.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

M>>>Мужик, это был 98й год, какие готовые ORM?

GZ>>CORBA.
AVK>И где там ты ORM увидел??? До версии 3.0 это был yet another OORPC.
Стандарт репозитория. Собственно из-за CORBA, эти козлы из ODMG распустились. Сказали что зафигом это надо, когда есть такие стандарты(поубивал бы).

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

IT>>Кеттел ван и солёные огурчики с меня

GZ>Местный первач? С удовольствием.

Обижаешь, местного я не пью даже пива

http://www.ketelone.com/ — водка из Нидерланд с русской историей.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>> Проблема в DLink. Чтобы остаться на рынке, нужно быть лучше чем оный. Вопрос только в чем.

M>Тут на днях Clemens Vasters выступил (довольно известный архитектор, недавно в MS перешел), наехал он на OR-мапперы непадецки, а когда его спросили, "а как же DLinq", он ответил следующее:
M>

M>Now you can (and some already have) ask how all of that plays with LINQ and, in particular, DLINQ. Mind that I don't work in the LINQ team, but I think to be observing a subtle but important difference between LINQ and O/R*:
M>
M>
O/R is object->relational mapping.
M>
LINQ is relational->object mapping.
M>
M>LINQ acknowledges the relational nature of the vast majority of data, while O/R attempts to deny it. LINQ speaks about entities, relations and queries and maps result-sets into the realm of objects, even cooking up classes on the fly if it needs to. It's bottom up and the data (from whatever source) is king. Objects and classes are just tooling. For O/R mapping, the database is just tooling.

Маркетинг чистой воды.

DLinq — нормальный ORMapper. В вопросах трансформации из физ. реляционной модели в логическую объектную каждый уважающий себя ORM выпендривается. Они выпендрились именно так. Трансформация объектов вплоть до операции проекции(что пожалуй нужно только для отчетов). На выходе все равно есть коллекция объектов. И при этом типизированных объектов(не важно, явно типизированных или неявно). DLink вполне самодостаточный ORM.

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

M>Тут на днях Clemens Vasters выступил (довольно известный архитектор, недавно в MS перешел), наехал он на OR-мапперы непадецки, а когда его спросили, "а как же DLinq", он ответил следующее:

Грамотный мужик, поддерживаю на 100%. Каждая часть приложения должна заниматься тем, что она умеет делать лучше всего.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>>LINQ acknowledges the relational nature of the vast majority of data, while O/R attempts to deny it. LINQ speaks about entities, relations and queries and maps result-sets into the realm of objects, even cooking up classes on the fly if it needs to. It's bottom up and the data (from whatever source) is king. Objects and classes are just tooling. For O/R mapping, the database is just tooling.

GZ>Маркетинг чистой воды.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>Главное я выделил.
LINQ и DLINQ — похожие вещи но с разными целями. Я вообще плохо понимаю зачем нужен LINQ. Только разве что для организации локального хранилища объектов. Я очень сомневаюсь что кому-то надо трансформить логическую модель. Сейчас разговор о DLinq. А он как раз и есть ORM.

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

IT>Принципиальное различие в том, что ORM скрывает от разработчика детали работы с БД. Точнее пытается скрыть, но делает это не всегда хорошо. Лично мне, как разработчику, понимающему что такое БД, этого, спасибо, не надо. Я даже считаю это вредным. Я хочу чтобы мне помогали, а не думали за меня. Если мне нужен сложный запрос к БД, то я хочу быть на 100% уверен в том, что он максимально эффективен и отлажен, я хочу посмотреть план и убедиться, что лишних ресурсов этот запрос не потребляет. Никакому ORM в этом случае я доверять не могу. Точнее скажем так. Я недостаточно уверен в том, что способен нарисовать такую объектную модель, которую подхватить ORM и эффективно отобразит её на реляционную структуру.
Собственно поэтому ORM кроме объектного языка запросов поддерживают нативные запросы SQL. Это с одной стороны ограничивает их, с другой стороны открывает дверь когда стандартной генерации не хватает. Это обычная практика.

IT>А маппинг — это дело десятое, это вообще перекладывание из пустого в порожнее. BLToolkit умеет перекладывать что попало во что угодно. БД лишь частный случай. В этом принципиальное отличие от ORM.
Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate.

Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.

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

GZ> Я вообще плохо понимаю зачем нужен LINQ.
Видишь ли... Настигала ли тебя мысль о том, сколько у тебя в проекте в среднем коллекций?
А Linq — это эффективный и простой способ делать запросы к этим коллекциям, ты все еще не понимаешь, зачем он нужен?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Собственно поэтому ORM кроме объектного языка запросов поддерживают нативные запросы SQL. Это с одной стороны ограничивает их, с другой стороны открывает дверь когда стандартной генерации не хватает. Это обычная практика.

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

I particularly liked the "Architectural Truthiness" post by David Ing and the comment by "Scott E" in my comments section who wrote:

I've hiked up the learning curve for Hibernate (the Java flavor) only to find that what time was saved in mapping basic CRUD functionality got eaten up by out-of-band custom data access (which always seems to be required) and tuning to get performance close to what it would have been with a more specialized, hand-coded DAL.

As always, it's a matter of perspective. Here is mine: I went down the O/R mapping route in a project in '98/'99 when my group at the company I was working for at the time was building a new business framework. We wrote a complete, fully transparent O/R mapper in C++. You walked up to a factory which dehydrated objects and you could walk along the association links and the object graph would either incrementally dehydrate or dehydrate in predefined segments. We had filtering capabilities that allowed to constrain 1:N collections with large N's, we could auto-resolve N:M relationships, had support for inheritance, and all that jazz. The whole framework was written with code generation in mind. Our generators were fed with augmented UML class diagrams and spit out the business layer, whereby we had a "partial classes" concept where we'd keep the auto-gen'd code in one tree and the parts that were supposed to be filled manually in another part of the code tree. Of course we'd preserve changes across re-gen's. Pure OO nirvana.

.....

That said, I am not for or against O/R mapping. There are lots of use cases with a lot of CRUD work where O/R saves a lot of time. However, it is a leaky abstraction. In fact is is so leaky that we ended up not using all that much of the funkyness we put into our framework, because "special cases" kept popping up. I am pointing out that there are a lot of fundamental differences between what an RDBMS does with data and how OOP treats data.

Вообщем вот, чтобы потом еще не бегать: http://friends.newtelligence.net/clemensv/PermaLink,guid,92eaea8c-778d-4512-af03-d332785f65f5.aspx

GZ>Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate.

Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.
Нафига еще один язык запросов, типа объектный, когда есть SQL?
*Linq в этом плане выгодно отличается от всех остальных мапперов тем, что в нем этот язык работает не только для нарошных ORM-ных объектов, но и вообще для любых коллекций...

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>Вообщем вот, чтобы потом еще не бегать: http://friends.newtelligence.net/clemensv/PermaLink,guid,92eaea8c-778d-4512-af03-d332785f65f5.aspx
Прочитал. Чувак сделал абсолютно прозрачный ORM и тем более на С++. Получилось то, что получилось. И поделом.

Современный ORM это значительно более сложная вещь. И не ограничевается CRUD. Основная его проблема в том, что он вместо того чтобы взять готовый ORM где уже проффесионально решены все эти проблемы, он решал их сам. К тому же, абсолютно прозрачный ORM — это гадость, поскольку подразумевает чистый Lazy Load. За такое убивать надо. Современный ORM — это не только CRUD.

GZ>>Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate.

Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.
M>Нафига еще один язык запросов, типа объектный, когда есть SQL?
Поясню.
Cервис должен обрабатывать ad-hook запрос. Хочу коллекцию объектов фильтрованных по 10 ссылке относительно объекта у которого параметр поставлен в true. Какие у нас варианты:
1. Сделать параметр в котором будет храниться строка SQL, или фильтр в терминах SQL references. Отметаем. Нельзя привязывать клиента к физ. базе SQL.
2. Делаем параметр в котором хранится фильтр в терминах логической модели.
Тут у нас есть варианты.
2.1 Мы отдаем это stored procedure, пускай он транслирует его в физ. термины и обрабатывает. Это значительно лучше чем п.1 но проблематичен. Во первых логика связи между реляционной и объектной схемой весьма сложна. Во вторых сложно делать парсинг запроса в T-SQL. В третьих мне придется также делать то же самое на PL/SQL.
2.2 Берем ORM(не важно DLinq или Hibernate) и строим запрос по логической схеме. Пускай он думает как сгенерить SQL в физических терминах. Его неглупые люди писали.
2.3 Загружаем все используемые объекты в коллекции, и с помощью Linq фильтруем. Даже пояснять не буду. Мрак.

M>*Linq в этом плане выгодно отличается от всех остальных мапперов тем, что в нем этот язык работает не только для нарошных ORM-ных объектов, но и вообще для любых коллекций...
Языки для XLinq, DLinq и Linq похожи но переносимы ли они?

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

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

GZ>> Я вообще плохо понимаю зачем нужен LINQ.
M>Видишь ли... Настигала ли тебя мысль о том, сколько у тебя в проекте в среднем коллекций?
M>А Linq — это эффективный и простой способ делать запросы к этим коллекциям, ты все еще не понимаешь, зачем он нужен?

Не-а.
1. В большинстве случаев для запросов хватает стандартного Array,Find с делегатом. Благо запросы в большинстве своем, работают по одной коллекции.
2. Запрос будет неудачен, если коллекция не подгружена. А подгрузку Linq делать просто так, не умеет.
Есть в принципе один вариант использования. Если будет репозиторий объектов при работе в стиле ocasionally connected smart client. Тогда мощность Linq может быть востребована.

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

GZ>>Современный ORM это значительно более сложная вещь.
M>Это мы запишем в минус современным ORM..

Это мы никуда не запишем. Не будешь же ты отказываться от реляционных баз данных, из-за того что они сложны. Я не призываю делать ORM. Я призываю использовать ORM (когда он нужен ессно).

GZ>>И не ограничевается CRUD.
M>А где там хоть слово, про то что их ORM ограничивался CRUD? Наоборот, был весьма навороченой конструкцией...
Первый параграф списка. Да и подразумевается, fully transparent O/R mapper подразумевает Lazy Load на фоне LCRUD.

GZ>>Основная его проблема в том, что он вместо того чтобы взять готовый ORM где уже проффесионально решены все эти проблемы, он решал их сам.
M>Мужик, это был 98й год, какие готовые ORM?

CORBA.

GZ>> К тому же, абсолютно прозрачный ORM — это гадость, поскольку подразумевает чистый Lazy Load. За такое убивать надо. Современный ORM — это не только CRUD.
M>Ты не понял, подвох в том, что ребята налабали афигительный ORM, который решал практически все проблемы работы с данными исключительно объектным способом... Pure OO nirvana. А оказалось, что все эти навороты нафиг не нужны, потому как слишком много "special cases", которые все равно надо обрабатывать в ручную..
Это просто неумение готовить. В то время у меня были точно такие же заскоки.

GZ>>2.1 Мы отдаем это stored procedure, пускай он транслирует его в физ. термины и обрабатывает. Это значительно лучше чем п.1 но проблематичен. Во первых логика связи между реляционной и объектной схемой весьма сложна.
M>Ничего сложного...
Ну-ну. То выполнение простых SQL запросов не подходит, так как логика слишком сложна. То наоборот, это все просто. Определись.

GZ>> Во вторых сложно делать парсинг запроса в T-SQL.
M>Зачем?
Затем что наименования объектов и полей должны не зависить от физической схемы. А следовательно, ad-hook запрос не является SQL запросом, и его нужно обрабатывать.

GZ>> В третьих мне придется также делать то же самое на PL/SQL.
M>Не придется. Я не верю в много БД-шные проекты, по крайней мере в те, где все это делает один человек.
А кто говорил что один.

Это нормальная практика тиражируемого софта.

GZ>>2.2 Берем ORM(не важно DLinq или Hibernate) и строим запрос по логической схеме. Пускай он думает как сгенерить SQL в физических терминах. Его неглупые люди писали.
M>Какие-бы неглупые люди не были, они не могли предумотреть всех частных случаев, о чем и пишет Вастерс, а частных случаев, на практике, оказывается лишком много.
В той схеме которую он сделал, частных случаев как грязи. В том же Hibernate их значительно меньше. Единственный стоящий вопрос — просадка производительности некоторых частных случаев.

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

GZ>Это мы никуда не запишем. Не будешь же ты отказываться от реляционных баз данных, из-за того что они сложны.
Сложны? Да они просты как рельс...

GZ>Я призываю использовать ORM (когда он нужен ессно).
Когда нужен — не вопрос...

M>>А где там хоть слово, про то что их ORM ограничивался CRUD? Наоборот, был весьма навороченой конструкцией...
GZ>Первый параграф списка.
Первый параграф списка говорит о том, что CRUD очень просто использовать с ORM, но вовсе не то, что их ORM этим ограничивался.

GZ> Да и подразумевается, fully transparent O/R mapper подразумевает Lazy Load на фоне LCRUD.
Это ты подразумеваешь..

M>>Мужик, это был 98й год, какие готовые ORM?

GZ>CORBA.
Ага. точно. зашибись готовый ORM.

GZ>Это просто неумение готовить.

GZ>Ну-ну. То выполнение простых SQL запросов не подходит, так как логика слишком сложна. То наоборот, это все просто. Определись.

Логика сложная, связать ее не сложно.

GZ>Затем что наименования объектов и полей должны не зависить от физической схемы. А следовательно, ad-hook запрос не является SQL запросом, и его нужно обрабатывать.
Тот же RFD справляется с этой задачей даже не почесавшись.

GZ>А кто говорил что один.

Ты говоришь, "мне придется". Придется не тебе, оракл-девелопер сделает это для оракла, сиквел для сиквела... Я уже не говорю о том, что при таком сценарии (несколько баз), в идеале структура баз под разные сервера будет разной и тут уж точно ни один ORM не разгребется.

GZ>В той схеме которую он сделал, частных случаев как грязи. В том же Hibernate их значительно меньше.
Их как бы там не больше, в том же гибернейт.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

IT>Я недостаточно уверен в том, что способен нарисовать такую объектную модель, которую подхватить ORM и эффективно отобразит её на реляционную структуру.
GZ>Собственно поэтому ORM кроме объектного языка запросов поддерживают нативные запросы SQL. Это с одной стороны ограничивает их, с другой стороны открывает дверь когда стандартной генерации не хватает. Это обычная практика.

Из ненативных запросов SQL реальная польза может быть только от базовых CRUDL операций. Их в программе может быть достаточно много, чтобы их надоело набивать. Но генератор для них пишется за пару дней. В BLToolkit у меня на это ушло не больше времени. Дальнейшие навороты ORM вместе с фичами добавляют массу ограничений, правил, соглашений и условностей. И вот после того как ты им безукоризненно следовал тебе вдруг говорят, а вот здесь в самом интересном месте, тебе придётся воспользоваться нативными запросами. И тут ты понимаешь, что ты заточил всю архитектуру под конкретный ORM, а тебя обманули.

IT>>А маппинг — это дело десятое, это вообще перекладывание из пустого в порожнее. BLToolkit умеет перекладывать что попало во что угодно. БД лишь частный случай. В этом принципиальное отличие от ORM.
GZ>Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate.

Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.

А мапер из них можно выдернуть? Что если у меня источник XML, comma delimitted поток или объектная модель соседа?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

C>Ага, конечно. У нас тут уже люди занимаются в проекте, где вся логика в SP (по заветам компании Microsoft и их MCSD) — могу написать их впечатления.

SP не предназначена для написания бизнес логики. Это обсуждалось уже миллион раз. А вот в одном моём проекте народ без конца матерился на хибернейт. Тоже наверно не от хорошей жизни.

C>Для совсем частных случаев используем голые SQL-запросы и мапим их результат на объекты. В совсем крайнем случае — используем результат напрямую.

Крайние случаи ещё не стали повседневным делом?

C>Смысл в том, что 90-99% обычных запросов замечательно генерируются ORMами. А это уже значительно упрощает работу.

99?

Верится с трудом. Вы что одни справочники выпускаете? Процентов в 70-80 поверю. Но оставшиеся 20-30% это как раз то на чём можно легко обломаться вместе с любым ORM. Зачастую такие запросы нужно тщательно отлаживать, гонять на реальных объёмах данных, иногда ради повышения производительности корректировать дизайн БД. А как насчёт запросов, в которых участвуют таблицы никак не представленные в объектной модели? Например, такое вполне возможно при подджоивании таблиц секьюрити. Они могут понадобиться практически в каждом запросе.

... << RSDN@Home 1.2.0 alpha rev. 0>>

IT wrote:
> C>Ага, конечно. У нас тут уже люди занимаются в проекте, где вся логика
> в SP (по заветам компании Microsoft и их MCSD) — могу написать их
> впечатления.
> SP не предназначена для написания бизнес логики. Это обсуждалось уже
> миллион раз. А вот в одном моём проекте народ без конца матерился на
> хибернейт. Тоже наверно не от хорошей жизни.
В первый раз я тоже матерился. Во второй раз уже понял как надо
использовать Hibernate.

В одном нашем текущем проекте люди тоже ругаются на Hibernate, в
основном из-за того, что изначально была выбрана неправильная стратегия
его использования (длинные сессии с непонятным циклом жизни).

> C>Для совсем частных случаев используем голые SQL-запросы и мапим их
> результат на объекты. В совсем крайнем случае — используем результат
> напрямую.
> Крайние случаи ещё не стали повседневным делом?
99% повседневных задач — рутина, и если Hibernate возьмет ее на себя, то
на оставшийся 1% больше останется времени.

> 99? Верится с трудом. Вы что одни справочники выпускаете?
Нет. Например, сейчас люди пишут систему учета рабочего времени — там на
SQL только репорты (что вполне логично). Большая часть — достаточно
простые запросы.

> А как насчёт запросов, в которых участвуют таблицы никак не
> представленные в объектной модели?
Hibernate'у по сути нужны id-шники объектов и их типы (ну и еще возможно
часть полей, чтобы их не надо было лениво подгружать). Если из
результата вашего запроса можно получить эти данные — то никаких проблем
нет.

> Например, такое вполне возможно при подджоивании таблиц секьюрити. Они
> могут понадобиться практически в каждом запросе.
Используйте Oracle, там есть row-level security прямо вмонтированый в
базу

Кстати, для безопасности в Hibernate есть очень удобная фича — можно
сделать простой фильтр на загрузку объекта, который будет смотреть
соответствует ли id объекта уровню доступа текущего пользователя.

А если еще поставить простой app-сервер и добавить remote lazy loading,
то у нас получается почтиобъектная база.

Posted via RSDN NNTP Server 2.0

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

C>TopLink, например. Был EJB CMP в Java, как зачаток ORM (совершенно неюзабельный, кстати).
Во-во, к тому же проект у них был сишный..

C>Ага, конечно. У нас тут уже люди занимаются в проекте, где вся логика в SP (по заветам компании Microsoft и их MCSD) — могу написать их впечатления.
А кто говорит о логике в SP?

C>Смысл в том, что 90-99% обычных запросов замечательно генерируются ORMами. А это уже значительно упрощает работу.
Вот эти числа (90-99) очень серьезно зависят от конкретного проекта, и как правило все-таки существенно меньше. Причем здесь важно даже не процентное соотношение, а количество геморроя на строчку кода оставшихся от ORM процентов, которые все равно придется набивать в ручную...
Никто не призывает отказываться от ORM вообще, но и количество проектов, на которых использование готового ORM не заточенного именно под этот проект оправдано, гораздо меньше чем кажется на первый взгляд.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>>Это мы никуда не запишем. Не будешь же ты отказываться от реляционных баз данных, из-за того что они сложны.
M>Сложны? Да они просты как рельс...
Не заметил.

GZ>> Да и подразумевается, fully transparent O/R mapper подразумевает Lazy Load на фоне LCRUD.
M>Это ты подразумеваешь..

Нет. Это следует из контекста. Нормальный ORM не прозрачен.

M>>>Мужик, это был 98й год, какие готовые ORM?

GZ>>CORBA.
M>Ага. точно. зашибись готовый ORM.
Должен был быть таковым. Дурацкий ORM. И реализации хреновые.

GZ>>Ну-ну. То выполнение простых SQL запросов не подходит, так как логика слишком сложна. То наоборот, это все просто. Определись.

M>Логика сложная, связать ее не сложно.
Не понял?

GZ>>Затем что наименования объектов и полей должны не зависить от физической схемы. А следовательно, ad-hook запрос не является SQL запросом, и его нужно обрабатывать.
M>Тот же RFD справляется с этой задачей даже не почесавшись.
Она не справляется. Она и не ставит такой задачи как ad-hook запрос по объектной схеме.

GZ>>А кто говорил что один.

M>Ты говоришь, "мне придется". Придется не тебе, оракл-девелопер сделает это для оракла, сиквел для сиквела...
Не понял. Зачем нужно два человека если с этим вполне справится один.

M>Я уже не говорю о том, что при таком сценарии (несколько баз), в идеале структура баз под разные сервера будет разной и тут уж точно ни один ORM не разгребется.
Нет. В идеале, да и на практике, структура баз данных одна и та же. Также как едины правила нормализации в реляционках. Разница в типах данных и методах работы. Да даже если и разная, объектная схема должна быть одинаковая. И здесь как раз ORM рулит. Разница в маппировании выделена в отдельную декларативную схему, и задача лишь в том, чтобы для каждого типа БД подставлять свою схему.

GZ>>В той схеме которую он сделал, частных случаев как грязи. В том же Hibernate их значительно меньше.
M>Их как бы там не больше, в том же гибернейт.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Не заметил.

GZ>Нет. Это следует из контекста.
Из контекста этого не следует.

GZ>Нормальный ORM не прозрачен.

GZ>Должен был быть таковым. Дурацкий ORM. И реализации хреновые.
Вот видишь.

GZ>Она не справляется. Она и не ставит такой задачи как ad-hook запрос по объектной схеме.
Для запроса по объектной схеме нужен Linq — это к вопросу о том зачем он нужен, все остальное — костыли, причем не очень удачные.

GZ>Не понял. Зачем нужно два человека если с этим вполне справится один.

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

M>>Я уже не говорю о том, что при таком сценарии (несколько баз), в идеале структура баз под разные сервера будет разной и тут уж точно ни один ORM не разгребется.
GZ>Нет.
Не нет, а да.

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

GZ>Также как едины правила нормализации в реляционках.
Ага, щаз. Если правила нормализации мешают эффективной работе, то правила нормализации идут разговаривать о погоде. Причем в зависимости от ситуации, в одной базе правила нормализации уживаются с эффективностью и даже помогают, а в другой нет, и наоборот. И именно по этому при построении модели данных я не хочу закладываться на то, что точно такая же модель будет использоваться в другой бд.

И Вастерс как раз говорит об этом — ты пляшешь от объектной модели и заставляешь модель данных подстраиваться под нее, и это то чем занимаются большинство ORM, а это не верно.

GZ> Да даже если и разная, объектная схема должна быть одинаковая. И здесь как раз ORM рулит.
Вот здесь как раз ORM не рулит, так как фиг она сгенерит тебе разные запросы по разные БД, если ORM не заточена конкретно под твою задачу. А беда всего траха с ORM как раз в том, что в массе своей все как раз затачивают свою задачу под универсальную ORM, а не наоборот, как должно было бы быть. И происходит так потому, что "современные ORM очень сложная штука" (c) Ты. Поэтому эту сложность я как раз и записываю современным ORM в минус.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>Из ненативных запросов SQL реальная польза может быть только от базовых CRUDL операций. Их в программе может быть достаточно много, чтобы их надоело набивать. Но генератор для них пишется за пару дней. В BLToolkit у меня на это ушло не больше времени. Дальнейшие навороты ORM вместе с фичами добавляют массу ограничений, правил, соглашений и условностей. И вот после того как ты им безукоризненно следовал тебе вдруг говорят, а вот здесь в самом интересном месте, тебе придётся воспользоваться нативными запросами. И тут ты понимаешь, что ты заточил всю архитектуру под конкретный ORM, а тебя обманули.

Не стоит забывать про полезности ОРМ
— вычитка и сохранение графа объектов (уж если есть в системе визард, то в сессии можна держать этот граф);
— поддержка транзакций в моделях;
— контроль изменения свойств объектов (облегчается апдэйт);
— кэширование параметров СП;
— а самое главное — объект запроса в ОРМ — это класс, который можна ПРОТОТИПИРОВАТЬ — держать в сборке бизнес логики, в этом вся фишка — конрол фильтра на ГУИ всего лишь компонирует результирующий запрос из прототипов. Пртототипов не так уж и много, значит и множество результирующих запросов в законченном приложении есть конечно, а значит прекрасно кэшируются эти же запросы на сервере БД при выполнении. Тоже самое с сортировкой. Следовательно, очень большая часть рутины, тоесть ее реализайия — вполне обходимся ОРМ.

Минус — в каждом готовом ОРМ есть то. чего как-раз не хватает, особенно это относится к архитектуре самой модели и фабрик. Почему фабрик — чтобы варьировать реализацию модели — подставить свою. Просто не всегда умеют проектировать правильно

.

Вот мы писали аукцион. Есть админ зона и паблик. Так из всего, что надо было выполнить, всего лишь часть, отвечающая за подгрузку состояния бида в риалтайме — это реализовывальсь просто хранимым кодом, все остальное — чистый ОРМ, а скорость разработки была отличной.

Только ОРМ!!!

IT>>>А маппинг — это дело десятое, это вообще перекладывание из пустого в порожнее. BLToolkit умеет перекладывать что попало во что угодно. БД лишь частный случай. В этом принципиальное отличие от ORM.
GZ>>Это не что-то новое. Это делает практически любой ORM. И версантовцы, и тот же Hibernate.

Они все поддерживают кроме отдельного языка запросов, нативный SQL+stored procedures.

IT>А мапер из них можно выдернуть? Что если у меня источник XML, comma delimitted поток или объектная модель соседа?

Use BizTalk server

Merle wrote:
> Вот здесь как раз ORM не рулит, так как фиг она сгенерит тебе разные
> запросы по разные БД, если ORM не заточена конкретно под твою задачу.
Запросто сгенерируют. В Hibernate, например, для каждого провайдера
делается своя стратегия перевода HQL в SQL, это важно для paging'а,
например.

Ну а custom-запросы, действительно, придется переделывать (а их в любом
случае придется переделывать).

> беда всего траха с ORM как раз в том, что в массе своей все как раз
> затачивают свою задачу под универсальную ORM, а не наоборот, как должно
> было бы быть.
А под конкретную задачу — есть специальные хуки в ORM'ах. Hibernate3 уже
очень даже ничего.

Posted via RSDN NNTP Server 2.0

Merle wrote:
> C>TopLink, например. Был EJB CMP в Java, как зачаток ORM (совершенно
> неюзабельный, кстати).
> Во-во, к тому же проект у них был сишный..
TopLink тогда был для С++ и Smalltalk.

> C>Смысл в том, что 90-99% обычных запросов замечательно генерируются
> ORMами. А это уже значительно упрощает работу.
> Вот эти числа (90-99) очень серьезно зависят от конкретного проекта, и
> как правило все-таки существенно меньше.
Давайте вы приведете первые три-пять попавшихся запросов из логов RSDN?
Или давайте посмотрим код Janus'а. Запросы типа:

SELECT {0}
         m.[mid],
         m.[pid],
         m.[dte],
         m.[gid],
         m.[usernick],
         m.[subject],
         m.[uclass],
         m.[uid],
         m.[ismarked],
         m.[isread],
         m.[article_id],
         m.[readreplies],
         m.[name],
         ti.[this_rate]         AS [rate],
         ti.[this_smile]        AS [smiles],
         ti.[this_agree]        AS [agree],
         ti.[this_disagree]     AS [disagree],
         ti.[answers_count]     AS [a_count],
         ti.[answers_unread]    AS [a_unread],
         ti.[answers_rate]      AS [a_rate],
         ti.[answers_smile]     AS [a_smiles],
         ti.[answers_agree]     AS [a_agree],
         ti.[answers_disagree]  AS [a_disagree],
         ti.[answers_me_unread] AS [a_me_unread],
         ti.[answers_marked]    AS [a_marked]
FROM [messages] m
         INNER JOIN [topic_info] ti ON m.[mid] = ti.[mid]
WHERE ti.[gid] = {1} {2}

Ложатся почти один-в-один на Hibernate.

Posted via RSDN NNTP Server 2.0

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

GZ>>Нет. Это следует из контекста.
M>Из контекста этого не следует.
GZ>>Нормальный ORM не прозрачен.
M>

Для меня следует. Не первый год в дальнем космосе.

GZ>>Должен был быть таковым. Дурацкий ORM. И реализации хреновые.
M>Вот видишь.
Фактически они приклеили к задаче слона, и получили то, что получили. Полных реализаций репозиториев как не было, так и нет. Меня сильно охладили пыл к таким архитектурам работы по OODB. Вполне понятно, что без декларативного языка это всего лишь неэффективная LCRUD структура, и область применения таких систем сильно сужается.

GZ>>Она не справляется. Она и не ставит такой задачи как ad-hook запрос по объектной схеме.
M>Для запроса по объектной схеме нужен Linq — это к вопросу о том зачем он нужен, все остальное — костыли, причем не очень удачные.
Ну давай попробуй такую вещь. У нас есть BLToolkit и Link.
Есть следующий запрос Link.

from document where document.reg_num>'10' and document.rubric.name='rubruc'

И теперь скажи, какие операции будет делать BLToolkit, а что Linq.

M>Один с этим не справится, если проект сложенее калькулятора. Ну или справится так, что лучше бы не справлялся, либо по качеству либо по срокам.
И как эти люди справляются

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

M>>>Я уже не говорю о том, что при таком сценарии (несколько баз), в идеале структура баз под разные сервера будет разной и тут уж точно ни один ORM не разгребется.
GZ>>Нет.
M>Не нет, а да.
Нет. У меня третий проект с поддержкой разных баз данных. Возьми к примеру Janus. Он схемой отличается?(хотя по сравнению с проектами в которых работаю я, это похоже на калькулятор)

M>Там где структура одна и таже, она одинаково плохо работает на всех серверах,
Одинаково хорошо.

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

GZ>>Также как едины правила нормализации в реляционках.
M>Ага, щаз. Если правила нормализации мешают эффективной работе, то правила нормализации идут разговаривать о погоде. Причем в зависимости от ситуации, в одной базе правила нормализации уживаются с эффективностью и даже помогают, а в другой нет, и наоборот. И именно по этому при построении модели данных я не хочу закладываться на то, что точно такая же модель будет использоваться в другой бд.
Зря.

- Если у него мама еврей и папа еврей, то кто он? Русский?
— Папа у него голубь!

(с)Ширли-Мырли
Используемые операции практически одинаковы. Индексы, таблицы и Вьюхи есть и там и там. Если не использовать всякие выпендрежи(типа вложенных таблиц, которые не особо и нужны), то все одинаковое. Так почему я должен делать разные схемы для Oracle и MSSQL? Что я смогу этим добиться?(единственная кардинальная разность с которыми легко встретиться, это темповые таблицы, но это легко обходится).

M>И Вастерс как раз говорит об этом — ты пляшешь от объектной модели и заставляешь модель данных подстраиваться под нее, и это то чем занимаются большинство ORM, а это не верно.
ORM — это средство чтобы обеспечить независимость между моделью данных и объектной моделью. Это его основная цель. Вастерс взял некий допотопный вариант, объявил его объектно-реляционным маппингом, и начал с ним сравнивать. Это не наши методы.

GZ>> Да даже если и разная, объектная схема должна быть одинаковая. И здесь как раз ORM рулит.
M>Вот здесь как раз ORM не рулит, так как фиг она сгенерит тебе разные запросы по разные БД, если ORM не заточена конкретно под твою задачу.
Но ведь генерит же.

M>А беда всего траха с ORM как раз в том, что в массе своей все как раз затачивают свою задачу под универсальную ORM, а не наоборот, как должно было бы быть. И происходит так потому, что "современные ORM очень сложная штука" (c) Ты. Поэтому эту сложность я как раз и записываю современным ORM в минус.
ORM — это не некий модуль управляющий твоей задачей. ORM — это инструмент с помощью которого ты можешь отделить модель данных от объектной модели. Он всего лишь инструмент с помощью которого разработчик может построить эффективную, с его точки зрения, модель данных.

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

GZ>LINQ и DLINQ — похожие вещи но с разными целями. Я вообще плохо понимаю зачем нужен LINQ.

Странный вопрос. LINQ это языковая механика, а DLINQ это библиотека доступа к ADO.NET посредством LINQ. Без LINQ никакого DLINQ не было бы. Может ты имеешь ввиду Standard Query Operations?

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

>>А вот в одном моём проекте народ без конца матерился на хибернейт. Тоже наверно не от хорошей жизни.
C>В первый раз я тоже матерился. Во второй раз уже понял как надо использовать Hibernate.

Люди, которые его использовали — джависты, используют эту хрень уже не первый год и знают что делают.

>> 99? Верится с трудом. Вы что одни справочники выпускаете?
C>Нет. Например, сейчас люди пишут систему учета рабочего времени — там на SQL только репорты (что вполне логично). Большая часть — достаточно простые запросы.

А остальное справочники. Понятно. Помнишь я тебе как-то про твоё ИМХО говорил?

>> Например, такое вполне возможно при подджоивании таблиц секьюрити. Они могут понадобиться практически в каждом запросе.
C>Используйте Oracle, там есть row-level security прямо вмонтированый в базу

А Sybase или DB2 в качестве полиси компании не хотел?

C>Кстати, для безопасности в Hibernate есть очень удобная фича — можно сделать простой фильтр на загрузку объекта, который будет смотреть соответствует ли id объекта уровню доступа текущего пользователя.

Ну профильтруй полтора миллиона записей на RSDN при просмотре сообщений каждым пользователем. А я потом посмотрю что тебе скажут наши посетители.

C>А если еще поставить простой app-сервер и добавить remote lazy loading, то у нас получается почтиобъектная база.

А почему один? Тут нам сразу load балансер понадобится

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

M>>Мужик, это был 98й год, какие готовые ORM?

GZ>CORBA.

И где там ты ORM увидел??? До версии 3.0 это был yet another OORPC.

... << RSDN@Home 1.2.0 alpha rev. 642>>

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

C>Запросто сгенерируют.
Не верю.

просто в одной базе у меня объект из одной собирается, а в другой из трех. Вот как ORM будет это дело расхлебывать?

C> В Hibernate, например, для каждого провайдера
C>делается своя стратегия перевода HQL в SQL, это важно для paging'а,
C>например.
Если эта стратегия должна содержать на столько подробные описания, то чем она лучше обычного SQL-я?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Для меня следует. Не первый год в дальнем космосе.

Ню-ню... То есть ты споришь не с тем что на самом деле, а с тем, что для тебя следует, классная идея..

GZ>Фактически они приклеили к задаче слона, и получили то, что получили.
Фактически они написали ORM и оказалось, что он не помогает.

GZ>И теперь скажи, какие операции будет делать BLToolkit, а что Linq.
Сканировать, сравнивать и воззвращать отфильтрованную коллекцию.

GZ>И как эти люди справляются

А никак не справляются. Не работает либо один сервер, либо другой, либо оба сразу, что скорее всего.

GZ> Возьми к примеру Janus. Он схемой отличается?(хотя по сравнению с проектами в которых работаю я, это похоже на калькулятор)
Вот именно. Похоже на калькулятор, а схемой уже отличается.
Вообщем все твои примеры лишь подтверждают мою точку зрения.

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

GZ>Используемые операции практически одинаковы. Индексы, таблицы и Вьюхи есть и там и там. Если не использовать всякие выпендрежи(типа вложенных таблиц, которые не особо и нужны), то все одинаковое.
Еще раз тебе говорю, разница не в базовых структурах, а в том что модель данных построенная на этих структурах для каждого сервера будет немного различной, потому как сервера работают чуть-чуть по разному.

GZ> Так почему я должен делать разные схемы для Oracle и MSSQL?
Потому что в одном случае я обойдусь запросом, а в другом мне надо будет промежуточную агрегатную таблицу сделать и данные брать уже из нее. Вот как в этом случае будет твой ORM плясать?

GZ> Что я смогу этим добиться?
Большей эффективности, в связи с тем, что я смогу использовать потенциал конкретного сервера на 100%. Помоему это очевидно.
Да и большей гибкости и простоты разработки, так как я могу не закладываться на то, что эта же модель будет использоваться где-то еще.

GZ>ORM — это средство чтобы обеспечить независимость между моделью данных и объектной моделью. Это его основная цель.
А напрактике получается, что он больше обеспечивает зависимость, нежели независимость. И об этом у Вастерса тоже есть, почитай.

GZ>Вастерс взял некий допотопный вариант, объявил его объектно-реляционным маппингом, и начал с ним сравнивать. Это не наши методы.

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

GZ>Но ведь генерит же.

Тока фигня получается.

GZ>ORM — это не некий модуль управляющий твоей задачей. ORM — это инструмент с помощью которого ты можешь отделить модель данных от объектной модели. Он всего лишь инструмент с помощью которого разработчик может построить эффективную, с его точки зрения, модель данных.
Это в теории, а на практике получается наоборот.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

C>TopLink тогда был для С++ и Smalltalk.
Возможно, но учитывая амбициозность проекта этим ребятам было не актуально пользоваться готовыми средствами и я практически уверен, что у них ORM получился ни чем не хуже.

C>Давайте вы приведете первые три-пять попавшихся запросов из логов RSDN?
C>Или давайте посмотрим код Janus'а. Запросы типа:
С Янусом вообще отдельная история, если в форуме покопаться, то хорошо видно, какие приседания приходилось делать Владу с аксесом практически на каждом запросе, чтобы это хоть как-то шевелилось, с учетом того что Jet хинтов не понимает. Тут бы вообще весь гибернейт состоял из кастомных запросов.

C>Ложатся почти один-в-один на Hibernate.
Эти ложаться, другие нет. Я даже соглашусь с тем, что тех, которые ложаться — большинство, но проблема в том, что это не спасает.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>>Для меня следует. Не первый год в дальнем космосе.

M>Ню-ню... То есть ты споришь не с тем что на самом деле, а с тем, что для тебя следует, классная идея..

Я спорю с тем что там написано.

GZ>>Фактически они приклеили к задаче слона, и получили то, что получили.
M>Фактически они написали ORM и оказалось, что он не помогает.
Нет. Там значительно больше и другие проблемы. Для них не было первоочередной задачей сделать ORM.

GZ>>И теперь скажи, какие операции будет делать BLToolkit, а что Linq.
M>Сканировать, сравнивать и воззвращать отфильтрованную коллекцию.
Что будет делать BLToolkit? Загружать всю нефильтрованную коллекцию? А если будет фильтровать сам то откуда он возьмет SQL? И тогда причем тут Linq?

GZ>>И как эти люди справляются

M>А никак не справляются. Не работает либо один сервер, либо другой, либо оба сразу, что скорее всего.
Работает, все. Шуршит не по детски и под большой нагрузкой.

GZ>> Возьми к примеру Janus. Он схемой отличается?(хотя по сравнению с проектами в которых работаю я, это похоже на калькулятор)
M>Вот именно. Похоже на калькулятор, а схемой уже отличается.
Пример.

GZ>>Ну кое-что зависит, и используется как интелектуальное отказоустойчивое хранилище. Но не более того.
M>Вот видишь, то есть твой пример и здесь не катит — ты с базой толком не работаешь,
Если я ее пользую именно для того ради чего ее делали, это с базой толком не работаешь?

M>все запросы примитивны.
Если бы примитивны.

GZ>>Используемые операции практически одинаковы. Индексы, таблицы и Вьюхи есть и там и там. Если не использовать всякие выпендрежи(типа вложенных таблиц, которые не особо и нужны), то все одинаковое.
M>Еще раз тебе говорю, разница не в базовых структурах, а в том что модель данных построенная на этих структурах для каждого сервера будет немного различной, потому как сервера работают чуть-чуть по разному.
Пример в студию!!!

GZ>> Так почему я должен делать разные схемы для Oracle и MSSQL?
M>Потому что в одном случае я обойдусь запросом, а в другом мне надо будет промежуточную агрегатную таблицу сделать и данные брать уже из нее.
Пример в студию!!!

M>Вот как в этом случае будет твой ORM плясать?
ORM в данном случае вообще не причем. Мы говорим о разности схем. Без примера я не могу понять каким образом ты получаешь в одном случае аггрегированную таблицу, а в другом обходишься запросом.

GZ>> Что я смогу этим добиться?
M>Большей эффективности, в связи с тем, что я смогу использовать потенциал конкретного сервера на 100%. Помоему это очевидно.
Пример в студию!!!

M>Да и большей гибкости и простоты разработки, так как я могу не закладываться на то, что эта же модель будет использоваться где-то еще.
И каждую версию придется проверять и перепроверять полностью логику и наведенные ошибки от рассинхронизации изменений для разных схем? Дороговато получается.

GZ>>Вастерс взял некий допотопный вариант, объявил его объектно-реляционным маппингом, и начал с ним сравнивать. Это не наши методы.

M>С чего ты взял что он допотопный? Он лишь привел один пример, да и не только он, там параллельно есть те же приседания с гибернейтом, его-то уж допотопным не назовешь.
Потому что хотя бы для гибернейта, все его пункты не верны!

GZ>>Но ведь генерит же.

M>Тока фигня получается.
По разному. В подавляющем большинстве случаев результат нормальный. Для остатка есть SQL.

GZ>>ORM — это не некий модуль управляющий твоей задачей. ORM — это инструмент с помощью которого ты можешь отделить модель данных от объектной модели. Он всего лишь инструмент с помощью которого разработчик может построить эффективную, с его точки зрения, модель данных.
M>Это в теории, а на практике получается наоборот.
И в теории, и в практике. Объектная и реляционная модель завязаны друг на друга по предметной области. Разница лишь в форме обработки и правилах хранения. И задача ORM — предоставить интерфейс связи между этими моделями таким образом, чтобы обеспечить их независимость. Это ее задача, и она справляется с нею. А если у кого-то ошибка в ДНК, то инструменты не виноваты.

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

AVK>Странный вопрос. LINQ это языковая механика, а DLINQ это библиотека доступа к ADO.NET посредством LINQ. Без LINQ никакого DLINQ не было бы. Может ты имеешь ввиду Standard Query Operations?
Нет. Я имею ввиду применимость LINQ без DLINQ и XLINQ.

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

GZ>Нет. Я имею ввиду применимость LINQ без DLINQ и XLINQ.

И что там не так? Вот к примеру IT может написать свою реализацию LINQ для BLToolkit. Это плохо?

... << RSDN@Home 1.2.0 alpha rev. 642>>

Merle wrote:
> C>Запросто сгенерируют.
> Не верю.
> просто в одной базе у меня объект из одной собирается, а в другой из
> трех. Вот как ORM будет это дело расхлебывать?\
То есть? Поля объекта за-map-лены на несколько таблиц?

Это вообще примитивный случай — он просто пропишет в запросах join'ы по
id-шнику.

> C> В Hibernate, например, для каждого провайдера
> C>делается своя стратегия перевода HQL в SQL, это важно для paging'а,
> C>например.
> Если эта стратегия должна содержать на столько подробные описания, то
> чем она лучше обычного SQL-я?
Стратегия пишется один раз разработчиками Hibernate и содержит
большинство требуемых фич. Остальное — руками.

Posted via RSDN NNTP Server 2.0

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

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

GZ>>Нет. Я имею ввиду применимость LINQ без DLINQ и XLINQ.

AVK>И что там не так? Вот к примеру IT может написать свою реализацию LINQ для BLToolkit. Это плохо?
Это хорошо. Это очень хорошо. Но я не понимаю как.
Тот же вопрос.

Ну давай попробуй такую вещь. У нас есть BLToolkit и Link.
Есть следующий запрос Link.
from document where document.reg_num>'10' and document.rubric.name='rubruc'
И теперь скажи, какие операции будет делать BLToolkit, а что Linq.

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

GZ>Я спорю с тем что там написано.
Ты не споришь, ты обвиняешь их в криворукости. Извини, но в данном случае у меня к ним доверия больше. .

GZ> Для них не было первоочередной задачей сделать ORM.
Им даже было проще, им достаточно было сделать ORM для своей задачи.

GZ>Что будет делать BLToolkit? Загружать всю нефильтрованную коллекцию?
Нет конечно.

GZ>Работает, все. Шуршит не по детски и под большой нагрузкой.
Рад за тебя.

GZ>Пример.
Что пример? Поройся в форуме и содрогнись от выкрутасов, которые Влад городил для адекватной работы джета, а потом попытайся убедить меня что для сиквела так тоже будет нормально.

GZ>Если я ее пользую именно для того ради чего ее делали, это с базой толком не работаешь?
Ее ваще-то делали для несколько более продвинутых вещей.

GZ>Пример в студию!!!
GZ>Пример в студию!!!
Пример чего? Как агрегатную таблицу делать? Или для тебя новость, что в блокирровочнике это нормальная практика — для построения согласованных отчетов выносить часть данных в заранее посчитанные агрегаты? А для версионника этого делать не надо, так как он согласованность при чтении и так получит? Зато при сложных модификациях я на блокировочник могу положиться, а за версионником надо бдить?
Добро пожаловать в реальный мир.

GZ>ORM в данном случае вообще не причем.
Ну мы как бы его применимость обсуждаем...

GZ> Без примера я не могу понять каким образом ты получаешь в одном случае аггрегированную таблицу, а в другом обходишься запросом.
Странно, ты же собаку съел на разных серверах..

M>>Большей эффективности, в связи с тем, что я смогу использовать потенциал конкретного сервера на 100%. Помоему это очевидно.
GZ>Пример в студию!!!
То есть, ты утверждаешь, что для разных БД наиболее эффективной будет одна и та же схема данных?

GZ>И каждую версию придется проверять и перепроверять полностью логику и наведенные ошибки от рассинхронизации изменений для разных схем?
Это лучше чем проверять каждую версию на соответствие БД.

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

GZ>По разному.
Ну да, разная фигня...

GZ>В подавляющем большинстве случаев результат нормальный. Для остатка есть SQL.
Верно. Только проблема в том, что этот SQL частенько перевешивает все преимущества того, что получается нормально.

GZ> И задача ORM — предоставить интерфейс связи между этими моделями таким образом, чтобы обеспечить их независимость.
В теории да, а на практике получается, что ORM обеспечивает зависимость, а не независимость, в этом-то и проблема.

GZ> А если у кого-то ошибка в ДНК, то инструменты не виноваты.
Инструменты никогда не виноваты. А вот у кого и где ошибка — это еще вопрос...

... << RSDN@Home 1.2.0 alpha rev. 0>>

IT wrote:
> Люди, которые его использовали — джависты, используют эту хрень уже не
> первый год и знают что делают.
Значит плохо используют.

Хотя, инструменты бывают двух типов — неудобные и неиспользуемые.

> C>Нет. Например, сейчас люди пишут систему учета рабочего времени — там
> на SQL только репорты (что вполне логично). Большая часть — достаточно
> простые запросы.
> А остальное справочники. Понятно. Помнишь я тебе как-то про твоё ИМХО
> говорил?
Только вот эти справочники читают (и редактируют!) пользователи
географически распределенные по США. Причем "чтение справочника"
позволяет тут же смотреть расписание для всего отделения, с
drill-down'ами по отделам и т.п.

Да, это все еще и динамически обновляется в реальном времени.

> C>Используйте Oracle, там есть row-level security прямо вмонтированый в
> А Sybase или DB2 в качестве полиси компании не хотел?
В DB2 вроде тоже есть, Sybase никогда не использовал (и к счастью...).

> C>Кстати, для безопасности в Hibernate есть очень удобная фича — можно
> сделать простой фильтр на загрузку объекта, который будет смотреть
> соответствует ли id объекта уровню доступа текущего пользователя.
> Ну профильтруй полтора миллиона записей на RSDN при просмотре сообщений
> каждым пользователем. А я потом посмотрю что тебе скажут наши посетители.
Зачем фильтровать _все_ сообщения? Просто в запрос, загружающий объект,
добавляется ограничение по колонке с правами доступа.

> C>А если еще поставить простой app-сервер и добавить remote lazy
> loading, то у нас получается почтиобъектная база.
> А почему один? Тут нам сразу load балансер понадобится
Нет, так как lazy-loading обычно должен производиться внутри транзакции.
Хотя есть возможность каждый раз открывать новую транзакции при
обработке ленивой подгрузки с контролем версионности.

А load-ballancer, кстати, легко организовать, если взять кластер
MySQL-репликантов.

Ну а для совсем уж крутых дядечек — есть Tangasol Coherence.

Posted via RSDN NNTP Server 2.0

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

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

GZ>>Я спорю с тем что там написано.
M>Ты не споришь, ты обвиняешь их в криворукости.
Нет. Близорукости.

Немного разные вещи, но касательно данной статьи верно.

GZ>>Что будет делать BLToolkit? Загружать всю нефильтрованную коллекцию?
M>Нет конечно.
Тогда как? В результате получится что мы берем AST запроса, и по схеме генерим SQL запрос? То что тебя сейчас возмущает?

GZ>>Пример.
M>Что пример? Поройся в форуме и содрогнись от выкрутасов, которые Влад городил для адекватной работы джета, а потом попытайся убедить меня что для сиквела так тоже будет нормально.
Кто-то тут несколько раз утверждал что Access не база, и у меня не подымалась рука возражать.

GZ>>Если я ее пользую именно для того ради чего ее делали, это с базой толком не работаешь?
M>Ее ваще-то делали для несколько более продвинутых вещей.
Например.

GZ>>Пример в студию!!!
GZ>>Пример в студию!!!
M>Пример чего? Как агрегатную таблицу делать? Или для тебя новость, что в блокирровочнике это нормальная практика — для построения согласованных отчетов выносить часть данных в заранее посчитанные агрегаты? А для версионника этого делать не надо, так как он согласованность при чтении и так получит? Зато при сложных модификациях я на блокировочник могу положиться, а за версионником надо бдить?
Нет. Не новость. Но также для меня не новость, что если логика позволяет то отчеты делаются через OLAP, либо через хранимки в которых отчеты шуршат локально и выдается набор готовых сущностей. Там они делаются наиболее эффективно. Поэтому мимо(я даже намекал тебе про темповые таблицы, это из того же пункта).

GZ>>ORM в данном случае вообще не причем.
M>Ну мы как бы его применимость обсуждаем...
Мы обсуждаем твое заявление о том, что схема должна быть различной для одного и того же решения, но на разных БД(в том случае мое заявление касалось Oracle и MSSQL, хотя думаю с другими серьезными БД будет то же самое).

GZ>> Без примера я не могу понять каким образом ты получаешь в одном случае аггрегированную таблицу, а в другом обходишься запросом.
M>Странно, ты же собаку съел на разных серверах..

Поэтому и дивлюсь.

M>>>Большей эффективности, в связи с тем, что я смогу использовать потенциал конкретного сервера на 100%. Помоему это очевидно.
GZ>>Пример в студию!!!
M>То есть, ты утверждаешь, что для разных БД наиболее эффективной будет одна и та же схема данных?
Да. Мало того что утверждаю, я так работаю.

GZ>>И каждую версию придется проверять и перепроверять полностью логику и наведенные ошибки от рассинхронизации изменений для разных схем?
M>Это лучше чем проверять каждую версию на соответствие БД.
Проверять релиз нужно по любому. Вопрос в том, сколько кода будет написано, и сколько ошибок будет выявлено (или не выявлено). А рассинхронизация изменения для различных версий одного и того же, для меня очень больная тема(много шишек набил

).

GZ>>Потому что хотя бы для гибернейта, все его пункты не верны!
M>Верны. Более того, там есть отдельно именно про гибернейт.
Поэхали сново. Чтобы пальцем не показывали делаю правки в тексте. Попробуй возразить.

Given metadata to do the mapping, implementing CRUD functionality with an O/R mapper is quite easy. We had to put lots of extra metadata into our C++ classes back in the day, but with .NET and Java the metadata is all there and therefore CRUD O/R mapping is very low-hanging fruit on both platforms. That's why there's such a large number of projects and products.

Проехали. Единственное замечание что Hibernate это не CRUD.

Defining and resolving associations is difficult. 1:N is hard, because you need to know what your N looks like. You don't want to dehydrate 10000 objects to find a value in one of them or to calculate a sum over a column. That's work that's, quite frankly, best left in the database. I realize that some people worry how that leads to logic bleeding into the database, but for me that's a discussion about pureness vs. pragmatism. If the N is small, grabbing all related objects is relatively easy — unless you support polymorphism, which forces the mapper into all sorts of weird query trees. 1:N is so difficult because an object model is inherently about records, while SQL is about sets. N:M is harder.

В hibernate проблемы разрешены. И связи прописаны. Декларативный язык запросов есть. Только в путь.

"Object identity" is a dangerous lure. Every object has its own identifier. In memory that is its address, on disk that's some form of unique identifier. The idea of making the persistent identifier also the in-memory identifier often has the design consequence of an in-memory "running object table" with the goal of avoiding to load the same object twice but rather linking it appropriately into the object graph. That's a fantastic concept, but leads to all sort of interesting concurrency puzzles: What do you do if you happen to find an object you have already loaded as you resolve an 1:N association and realize that the object has meanwhile changed on disk? Another question is what the scope of the object identity is. Per appdomain/process, per machine or even a central object server (hope not)?

При чем тут проблема согласованности локального кэша и изменений, не знаю. Разницы от того, пользуешься ты ORM или не пользуешься — нет. Хочешь сохраняй сразу значения в БД, хочешь не сохраняй а держи в кэше. Есть ORM, нет — без разницы.

Transactions are hard. Databases are doing a really good job with data concurrency management, especially with stored procedures. If you are loading and managing data as object-graphs, how do you manage transaction isolation? How do you identify the subtree that's being touched by a transaction? How do you manage rollbacks? What is a transaction, anyways?

Можно использовать транзакции БД, можно использовать версионные транзакции hibernate(которых там несколько видов), можешь использовать пользовательские блокировки. Что хочешь, то используй. Непонятно в чем проблема.

Changing the underlying data model is hard. I've run into several situations where existing applications had to be, with the customer willing to put money on the table, be integrated with existing data models. O/R mapping is relatively easy of the data model falls out of the object model. If an existing data model bubbles up against an object model, you often end up writing a DAL or the O/R in stored procedures.

Здесь частично правда есть. При изменении некоторых требований нужно рефакторить. И тут уже сильный вопрос, насколько по умному сделана схема. После некоторой дельты изменений, уже придется не ставить подпорки, а рефакторить объектную схему. Но тут стоит посмотреть и на некоторую дельту. Эта дельта есть, и как результат не приходится выискивать, а чей-то в том то программе, в таком то модуле откуда-то вылетела ошибка. Вроде бы его и не трогали 100 лет. Да просто схемка была подредактирована.

В принципе, эта дельта вполне сопоставима с той дельтой, которую дают sp и вьюхи.

Reporting and data aggregation is hard. I'll use an analogy for that: It's really easy to write an XPath query against an XML document, but it is insanely difficult to do the same navigating the DOM.

Это уже обсуждали сверху. Stored procedure || OLAP должны быть по любому.

GZ>>В подавляющем большинстве случаев результат нормальный. Для остатка есть SQL.
M>Верно. Только проблема в том, что этот SQL частенько перевешивает все преимущества того, что получается нормально.
Здесь не понял.

Какие конкретно преимущества перевешивает?

GZ>> И задача ORM — предоставить интерфейс связи между этими моделями таким образом, чтобы обеспечить их независимость.
M>В теории да, а на практике получается, что ORM обеспечивает зависимость, а не независимость, в этом-то и проблема.
Ну давай еще раз. Во первых, зависимость есть всегда поскольку описывает одну и ту же предметную область и ее сущности(с Коддом и Дейтом спорить надеюсь не будешь

). Во вторых, ты можешь денормализовать схему до 5 НФ не изменяя объектной схемы, оперируя только самой трансформацией. Можешь сделать наоборот. Денормализовать реляционную схему оперируя только схемой маппинга. Если изменилась предметные сущности, то это общие проблемы независимо есть ORM, или нет ORM. Если нет, то ORM рулит.

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

GZ>И теперь скажи, какие операции будет делать BLToolkit, а что Linq.

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

... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>

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

GZ>Нет. Близорукости.

Немного разные вещи, но касательно данной статьи верно.
Не оглядываться на авторитеты это конечно иногда полезно, но давай все-таки сойдемся на том, что те ребята, как минимум, не глупее тебя. И занимались этими проблемами, когда ты о них даже не думал.
Из чего автоматически следует, что есть задачи, для которых ORM не подходит и даже объяснили почему.
Далее, никто не призывает вообще отказываться от ORM, указывают лишь на то, что область применения ORM довольно ограничена и опять-таки указывают почему. Можешь конечно не соглашаться, но поверь, им и на тот момент опыта было не занимать.

GZ>Тогда как? В результате получится что мы берем AST запроса, и по схеме генерим SQL запрос? То что тебя сейчас возмущает?

Меня возмущает не это. Меня возмущает то, что для того чтобы ORM понял что я от него хочу, он вынуждает строить и БД и объектную модель так
чтобы ему это было удобно.

GZ>Кто-то тут несколько раз утверждал что Access не база, и у меня не подымалась рука возражать.

Ты сам привел янус в качестве примера.

GZ>Нет. Не новость. Но также для меня не новость, что если логика позволяет то отчеты делаются через OLAP, либо через хранимки в которых отчеты шуршат локально и выдается набор готовых сущностей.
А если не позволяет?

GZ>Там они делаются наиболее эффективно. Поэтому мимо(я даже намекал тебе про темповые таблицы, это из того же пункта).

Не верно. То есть в OLAP конечно более эффективно, но это уже отдельный разговор, да и не отчетами едиными. А вот что касается хранимок с временными таблицами, то это только полумеры, нормальное решение — это как раз промежуточные агрегатные таблицы.
Это наиболее характерный пример разных схем, если не вспоминать про ограничения на длинну записи, манипуляции кластерными индексами, которым в оракле адекватной замены нет, управление порядком обхода таблиц и даже порядком обхода записей при сканировании, во избежание особо заковыристых дедлоков — это все отражается на оптимальной структуре данных. Где-то лишний столбец добавить, для промежуточных расчетов, где-то индекс по другому построить, где-то на две таблички разнести... Задолбаешься причесывать, чтобы одинаково эффективно работало везде.

GZ>Мы обсуждаем твое заявление о том, что схема должна быть различной для одного и того же решения, но на разных БД(в том случае мое заявление касалось Oracle и MSSQL, хотя думаю с другими серьезными БД будет то же самое).
Естественно тоже самое, схема под каждую БД будет своя.

GZ>Поэтому и дивлюсь.

О сколько нам открытий чудных...

GZ>Да. Мало того что утверждаю, я так работаю.

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

GZ> Попробуй возразить.
Да не вопрос. Возражение одно, но большое. Здесь он описывает принципиальные проблемы которые хороший ORM должен уметь решать. И их ORM все это решал, в той или иной мере, и все равно не помогло. А вовсе не проблемы которые ORM им не помог решить, как ты подумал....

GZ>Здесь не понял.

Какие конкретно преимущества перевешивает?
Конкретно ORM избавляет от рутины по набиванию примитивных SQL запросов, но зачастую это не стоит того, чтобы корежить свой проект так, чтобы это было удобно ORM.

GZ>Ну давай еще раз.
Не надоело?

GZ> Во первых, зависимость есть всегда поскольку описывает одну и ту же предметную область и ее сущности(с Коддом и Дейтом спорить надеюсь не будешь

).
С Коддом вряд ли, а вот с Дейтом периодически очень хочется. Только не очень понятно причем тут они оба.
Я говорю не о зависимости БД и кода друг от друга, а о зависимости и того и другого от ORM.

GZ> Во вторых, ты можешь денормализовать схему до 5 НФ не изменяя объектной схемы, оперируя только самой трансформацией. Можешь сделать наоборот. Денормализовать реляционную схему оперируя только схемой маппинга.
А в чем проблема?

GZ> Если нет, то ORM рулит.
А туда ли рулит ORM?

... [RSDN@Home 1.2.0 alpha rev. 619]

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

>> Люди, которые его использовали — джависты, используют эту хрень уже не первый год и знают что делают.
C>Значит плохо используют.

Может они не только справочники пишут

>> Ну профильтруй полтора миллиона записей на RSDN при просмотре сообщений каждым пользователем. А я потом посмотрю что тебе скажут наши посетители.
C>Зачем фильтровать _все_ сообщения? Просто в запрос, загружающий объект, добавляется ограничение по колонке с правами доступа.

Кем добавляется?

C>Нет, так как lazy-loading обычно должен производиться внутри транзакции. Хотя есть возможность каждый раз открывать новую транзакции при обработке ленивой подгрузки с контролем версионности.

ORM + lazy-loading — это как раз то, что нужно настоящему индейцу для полного счастья. Потом будет чем объяснять тормоза заказчику

Ты в курсе, что lazy-loading — это один шаг в сторону и сразу расстрел? Или я его опять готовить не умею

C>А load-ballancer, кстати, легко организовать, если взять кластер MySQL-репликантов.

Пробовал? Брал?

C>Ну а для совсем уж крутых дядечек — есть Tangasol Coherence.

Tangosol. Впрочем, java всё равно суксь

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

D_A>>Не стоит забывать про полезности ОРМ

IT>Полезный выхлоп у ORM безусловно есть. Иначе бы им вообще никто не пользовался. Вопрос в том, что перевешивает.

в таком случае нужно просто составить список из необходимых в разработке фич, и провести сравнительную характеристику для ОРМ и еще чего там...
Думаю, над конкретным + или — можно спорить — так удобнее

D_A>>- вычитка и сохранение графа объектов (уж если есть в системе визард, то в сессии можна держать этот граф);

IT>Зачем?

D_A>>- поддержка транзакций в моделях;

IT>Stateful? Зачем?

собственно, подсуммирую все выше сказанное:
СтейтФул нужен в том месте, где присутсвует визард — например на 1 скрине создаем адрес, на втором заполняем адреса, дальше — кредитки. И — самое главное — пользователь может нажать Отмена — данных в базе нет.
Сдесь как никак нужна сессия (конечно, накапливаемое состояние можно перебрасывать из страницы в страницу в хидден элементе), но опять же, в простом случае прибегать к усложнению архитектуры там, где это не востребовано — не стоит, а значит — сессия. Там накопится парочку объектов, а потом в конце все красивенько заливается, подстанавляваются первичный ключи, собственно, такая задача решается легко.

D_A>>- контроль изменения свойств объектов (облегчается апдэйт);

IT>Это всё делается и без ORM.

согласен, лучший способ — иметь базовый абстрактный класс модели, всю остальную специфику догенерим в памяти — РФД.
или вручную все красивенько тайпать, что мне не в прикол.
То, чего всегда хотел от ОРМ — это детальное настраивание режима генерации, мол, хочешь трэкинг изменений — на, сгенерить фабрики, там заглушки. В таком случае мы получаем на выходе прекрасно работающий, быстрый код, но самое главное — мы его не пишем, вовсе, что исключает возможность допущенной ошибки, конечно, если ОРМ тестили

D_A>>- кэширование параметров СП;

IT>ORM тут тоже не при чём.

ну да просто некоторые это делают — генерят типизированные методы для ХП. Как по мне — удобно. Вообще не хочу видеть System.Data.
Еще 1 мечта — пусть ОРАКЛ — пакеты. Типизированные методы процедур и функций пакетов можно раскладывать по статическим классам — уже лучше, хотя, интерфейс ХП может меняться часто, и это — первый настораживающий сигнал для решения, использовать ОРМ для ХП или нет. Наверное — нет. Для вызова ХП можно и самому писать код, ладно, лишь бы параметры кэшировал.

D_A>>- а самое главное — объект запроса в ОРМ — это класс

IT>В BLToolkit ExecuteList и ExecuteObject тоже возвращают объекты. Причём какие хочешь объекты, без всяких искуственных ограничений типа прибитых гвоздями базовых классов от ORM. Это делается с помощью простейших мапперов и функций хелперов.

D_A>>, который можна ПРОТОТИПИРОВАТЬ — держать в сборке бизнес логики, в этом вся фишка — конрол фильтра на ГУИ всего лишь компонирует результирующий запрос из прототипов. Пртототипов не так уж и много, значит и множество результирующих запросов в законченном приложении есть конечно, а значит прекрасно кэшируются эти же запросы на сервере БД при выполнении. Тоже самое с сортировкой. Следовательно, очень большая часть рутины, тоесть ее реализайия — вполне обходимся ОРМ.

IT>Фильтрация и сортировка, особенно во втором фреймворке делается штатными средствами как два байта.

Я немного не про то. в ЛЛБЛГЕН ПРО есть классик RelationPredicateBucket — инкапсулирует запрос, в нем есть набор рилэйшенов — джоины (для каждого существующего — сгенеренный прототип инстана), и собственно — условие выборки. Так вот части этого объекта можно прототипировать в БЛ — тогда ГУИ проект для постороения запроса по фильтрам просто суммирует прототипы, мол, что надо, то и возьмем. Так даже очень прикольно.

Я имел ввиду сложный запрос в БД. Использовать 2ой фрэймворк — дело весьма рискованное. Как по мне, многие решения не есть полностью удовлетворяющими для построения надежного приложения (заказчику заявлять про сложности изза Микро не станешь), а еще более угнетающий факт — многие решения просто непригодны для нативного расширения — тоесть легкого. Себе покачто доверяю больше.

D_A>>Минус — в каждом готовом ОРМ есть то. чего как-раз не хватает, особенно это относится к архитектуре самой модели и фабрик. Почему фабрик — чтобы варьировать реализацию модели — подставить свою. Просто не всегда умеют проектировать правильно

.

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

А что собственно плохого в срого выстроенной архитектуре? ОРМ генерирует модели — пассивные контейнеры. Для меня это главное, тем более, что они все выдержаны в одном стиле и есть сразу. Группа разработки садится и штопает — пускай 80% убивается ОРМ, пускай в остальный случаях мне нужна какаято фасадная функциональность, так для этого существует композиция, фасад, медиатор — неважно.
Имея огромную часть работающего сгенерированного кода уж точно куда проще написать функционал.
Ну уж если всеже надо без его архитектуры — то даже в контексте ОРМ транзакции можно выдернуть IDbConnection из ОРМ коннекшн-представления, и крутить-вертеть им.

D_A>>Вот мы писали аукцион. Есть админ зона и паблик. Так из всего, что надо было выполнить, всего лишь часть, отвечающая за подгрузку состояния бида в риалтайме — это реализовывальсь просто хранимым кодом, все остальное — чистый ОРМ, а скорость разработки была отличной.

D_A>>Только ОРМ!!!

IT>Хочешь посоревноваться?

Можем чтото споэктировать убийственное

Свой ОРМ я уже спроэктировал

— полность типизированный, тоесть если вбираешь из Юзера, то в список полей могут попасть только поля таблицы Юзера — 2ой фрэймворк очень помог.

IT>>>А мапер из них можно выдернуть? Что если у меня источник XML, comma delimitted поток или объектная модель соседа?

D_A>>Use BizTalk server

IT>Да, это как раз то, что надо. $25k на процессор за переливание из пустого в порожнее.

Да, рекламу гонят, а 25к — это его цена?
Все равно чтото в нем етсь — сама концепция неплохая, задачи бы подходящие

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

GZ>>Нет. Близорукости.

Немного разные вещи, но касательно данной статьи верно.
M>Не оглядываться на авторитеты это конечно иногда полезно, но давай все-таки сойдемся на том, что те ребята, как минимум, не глупее тебя. И занимались этими проблемами, когда ты о них даже не думал.
Да похоже на то, что плохо занимались. Проблемы ясны, опубликованы, и много раз обговорены. Это практик. Его проблема, что он позиционирует свое мнения согласно тому опыту, который он получил. Вот те продукты с которыми он работал, ему хорошо известны, и по ним он может составить квалифицированное мнение. Может поэтому мне больше нравятся теоретики, которые мыслят более полными понятиями и категориями, невзирая на существование или несуществование таких понятий в реальности.
Я ни минуту не сомневаюсь, что Clemens Vasters, есть хороший человек, добрый семьянин, и прекрасный архитектор с огромным опытом. Судя потому, как ты называешь его авторитетом, значит этот человек пользуется заслуженным авторитетом как архитектор. Но вполне можно быть вечно архитектором, и не использовать ORM и не отслеживать современное состояние данного направления. Или сознательно принижать(или не упоминать) в рекламных целях(а он как ты заметил теперь работает в Microsoft) функциональность современных серьезных ORM систем. Собственно по той же причине ты сам критиковал 12 правил реляционной системы такого всеобщего авторитета как господина Кодда. Мне не хотелось бы разбираться в причинах произошедшего, точнее верить во вторую версию, поэтому я предположил что г-н Clemens Vasters просто не в теме современных ORM систем.

M>Из чего автоматически следует, что есть задачи, для которых ORM не подходит и даже объяснили почему. Далее, никто не призывает вообще отказываться от ORM, указывают лишь на то, что область применения ORM довольно ограничена и опять-таки указывают почему.
Есть задачи которым не подходит ORM. Это то в чем я абсолютно согласен и могу подписаться под любым документом.
Я абсолютно не согласен с аргументацией. Есть ли у ORM недостатки? Конечно есть. Но то, что написал г-н Clemens Vasters не выдерживает критики. Собственно ты сам мне не возразил ни по одному пункту в предыдущем посте. Интересно почему?

M>Можешь конечно не соглашаться, но поверь, им и на тот момент опыта было не занимать.
Могу поверить, но существуют и другие люди, которым опыта не занимать(и это отнюдь не я).
Итак, ты никак конструктивно не возразил моей критике, давай-ка попробуй возразить следующим утверждениям. Недостатки ORM+RDB.

1. Избыточное чтение данных. ORM работает с типизированными сущностями. Сущности должны быть консистентны в памяти, а потому загружаются полностью. Хотя если мы будем работать напрямую с моделью данных, мы можем брать только те данные которые нужно в тот или иной момент. Его достоинство, то есть возможность соблюдения некоторых внутренних правил консистентности оборачивается избыточностью чтение. Притом что самое замечательное, когда спросили Bruce Lindsey(а это один из тех людей которые делали SystemR) о проблемах взаимодействия между OOП и хранилищем, это было первое его замечание.
2. ORM, несмотря на декларативные языки, имеют тенденцию к навигационному доступу. А вот реляционное хранилище не имеет средств для решения подобных задач. Хотя и в данном вопросе есть некоторые прогресс, например Oracle выпустил продукт которые кэширует данные локально, и в котором можно не бояться использовать навигационный доступ(по крайней мере как они говорят). Без подобного продукта можно организовавать локальное кэширование которое снизит нагрузку.
3. Рассогласования объекта и таблиц. Есть версия лежащая на диске, есть версия находящаяся в памяти. Язык запросов генерящий в свою очередь SQL, работает с версией на диске. Программа работает с версиями в памяти.
4. Рассогласованность декларативного языка ORM и декларативного языка SQL. Рассогласованность достаточно огромна. Обычно, генерируемый SQL просто страшен. Множество повторяемых конструкций, которые не все базы данных могут выполнить без повторения. Получить оптимизированный SQL запрос невозможно, но для этого открывают некоторую заднюю дверцу. Можно это сделать вручную. Базы данных идут навстречу (если вспомнить тот же MARS) объектным системам.
5. Не умеет эффективно делать массовый update. Штука редкая в бизнес-приложениях, но иногда нужная.
6. Многие действия можно (или желательно) выполнять именно на модели данных. То есть, те же примеры с аггрегированными промежуточными таблицами. Можно включить функции и работать на них, это не проблема. Но это может перейти некоторую грань, когда чужеродным для системы будет не выполнение логики в хранилище, а именно сама ORM система. Обычно это системные вещи обслуживающие предметную область.
7. Нет интеграции с сопуствующими технологиями. С тем-же OLAP, например.

GZ>>Тогда как? В результате получится что мы берем AST запроса, и по схеме генерим SQL запрос? То что тебя сейчас возмущает?

M>Меня возмущает не это. Меня возмущает то, что для того чтобы ORM понял что я от него хочу, он вынуждает строить и БД и объектную модель так
M>чтобы ему это было удобно.
Да ничему он тебя не обязывает.

Это уже у тебя в голове засело.

GZ>>Кто-то тут несколько раз утверждал что Access не база, и у меня не подымалась рука возражать.

M>Ты сам привел янус в качестве примера.
Янус держит много баз данных(а не эту поделку).

GZ>>Нет. Не новость. Но также для меня не новость, что если логика позволяет то отчеты делаются через OLAP, либо через хранимки в которых отчеты шуршат локально и выдается набор готовых сущностей.
M>А если не позволяет?
Не позволяют конструкторы. Если у пользователя есть конструктор с помощью которого он сам собирает себе отчет(у меня такое часто). И тут уже начинаются его проблемы, которым не очень то и поможешь.

GZ>>Там они делаются наиболее эффективно. Поэтому мимо(я даже намекал тебе про темповые таблицы, это из того же пункта).

M>Не верно. То есть в OLAP конечно более эффективно, но это уже отдельный разговор, да и не отчетами едиными. А вот что касается хранимок с временными таблицами, то это только полумеры, нормальное решение — это как раз промежуточные агрегатные таблицы.
И кто тебе мешает их сделать и там и там? Мне собственно такой шнягой заниматься не приходилось, но я думаю что при таких криминальных условиях, промежуточная таблица и в Oracle даст положительный результат.
M>Это наиболее характерный пример разных схем, если не вспоминать про ограничения на длинну записи,
Засчитано. Приходится ограничивать. Я против такого и не возражал.
M>манипуляции кластерными индексами, которым в оракле адекватной замены нет,
Это еще почему?

Поклеп. Там все мощнее. Ты можешь держать таблицу отсортированной по любому индексу а не только по primary.
M>управление порядком обхода таблиц и даже порядком обхода записей при сканировании, во избежание особо заковыристых дедлоков
+1 Задолбали уже. Правда это к общей схеме мало относится.
M>- это все отражается на оптимальной структуре данных. Где-то лишний столбец добавить, для промежуточных расчетов,
Так рассчеты везде одинаковы.
M>где-то индекс по другому построить,
Такие кишки к схеме не относятся.
M>где-то на две таблички разнести... Задолбаешься причесывать, чтобы одинаково эффективно работало везде.
Да нормально все работает. Логика одна, предметная область одна, зависимости в процедурах и функциях (правда которые в свою очередь по разному работают

). Сиди и собирай денюжки.

M>Надо отдать должное разработчикам СУБД, они их довели до такого состояния, что они очень прилично работают в самых сложных условиях...
И я им благодарен.

GZ>> Попробуй возразить.
M>Да не вопрос. Возражение одно, но большое. Здесь он описывает принципиальные проблемы которые хороший ORM должен уметь решать. И их ORM все это решал, в той или иной мере, и все равно не помогло.
Извини. Нигде в тексте такого не увидил. Более того, не увидел никакой ссылки на язык запросов. Просто pure OO. А этого мало.
M>А вовсе не проблемы которые ORM им не помог решить, как ты подумал....

While the platforms have evolved substantially in the past 7 years, the fundamental challenges for transparent (fully abstracted) mapping of data to objects remain essentially the same.

Перевести?

GZ>>Здесь не понял.

Какие конкретно преимущества перевешивает?
M>Конкретно ORM избавляет от рутины по набиванию примитивных SQL запросов, но зачастую это не стоит того, чтобы корежить свой проект так, чтобы это было удобно ORM.
Да нет. Корявый SQL это да. Это там большая проблема. Корявая схема нет.

GZ>>Ну давай еще раз.
M>Не надоело?
Уже да.

GZ>> Во первых, зависимость есть всегда поскольку описывает одну и ту же предметную область и ее сущности(с Коддом и Дейтом спорить надеюсь не будешь

).
M>С Коддом вряд ли, а вот с Дейтом периодически очень хочется. Только не очень понятно причем тут они оба.
M>Я говорю не о зависимости БД и кода друг от друга, а о зависимости и того и другого от ORM.

GZ>> Во вторых, ты можешь денормализовать схему до 5 НФ не изменяя объектной схемы, оперируя только самой трансформацией. Можешь сделать наоборот. Денормализовать реляционную схему оперируя только схемой маппинга.
M>А в чем проблема?

GZ>> Если нет, то ORM рулит.
M>А туда ли рулит ORM?
Туда, туда. Только просто нужно рулить не отдельно, а вместе с базоведами.(вот у Microsoft'а ObjectSpace появился, так и сразу в SQL MARS появился, и оптимистические транзакции. Связь между ними, как бы не факт, но чрезвычайно вероятно).

И славо богу. А то сказочки про чудесный LCRUD в DAL уже начинают надоедать.

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

GZ>Итак, ты никак конструктивно не возразил моей критике, давай-ка попробуй возразить следующим утверждениям. Недостатки ORM+RDB.

Глеб, к сожалению ты не понял главного. Всё перечисленное — это не недостатки ORM, а лишь следствия. Главный недостаток ORM — это прежде всего недвусмысленное отстранение разработчика от задач разработки БД. Эта штука обещает всё сделать за нас. Иногда у неё это получается, но не всегда. Если ты способен уловить все "не всегда", то ORM станет неплохим дополнением твоим стараниям. Если ты этот процесс не контролируешь, то всё что тебе остаётся — это молиться и молиться усердно.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>Глеб, к сожалению ты не понял главного. Всё перечисленное — это не недостатки ORM, а лишь следствия. Главный недостаток ORM — это прежде всего недвусмысленное отстранение разработчика от задач разработки БД. Эта штука обещает всё сделать за нас. Иногда у неё это получается, но не всегда. Если ты способен уловить все "не всегда", то ORM станет неплохим дополнением твоим стараниям. Если ты этот процесс не контролируешь, то всё что тебе остаётся — это молиться и молиться усердно.
Это вы чего-то не понимаете. ORM — не отстраняет разработчика от разработки БД. Никогда и нигде. Он берет на себя работу по независимости модели данных и объектной модели с помощью типовых схем. То есть, то что реализуется обычно с помощью вьюх и процедур. Или вообще не реализуется. Всего лишь независимости, а не схемы. Внутренние механизмы, сама схема БД — это есть обязанность разработчика и она мало зависит от ORM. ORM — это всего лишь инструмент, но не более того. Не ORM пишет базу. ORM связывает две схемы которые описывают одну логическую модель. А на схему данных, влияет только логическая модель, да понятия эффективности.
И кстати, не забывай. BLToolkit точно такая же ORM как и другие. Просто сильно недоделанная. Она делает абсолютно то же самое что и другие. Просто и типовых шаблонов как таковых раз-два и обчелся, поэтому ест тенденция работы прямыми вызовами, и дополнительных инструментов мало.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>>И теперь скажи, какие операции будет делать BLToolkit, а что Linq.
AVK>LINQ будет обеспечивать компиляцию, BLToolkit рантайм. А что, есть другие варианты?
Да даже в данном варианте жутко непонятно. Я предложил конкретный сценарий. Каким образом он может быть выполнен использую эти две вещи?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

AVK>>LINQ будет обеспечивать компиляцию, BLToolkit рантайм. А что, есть другие варианты?
GZ>Да даже в данном варианте жутко непонятно. Я предложил конкретный сценарий. Каким образом он может быть выполнен использую эти две вещи?

У меня тут тоже сценарий есть. Каким образом я могу, используя твои теории его осуществить?

Какое отношение твой сценарий имеет к сопряганию linq и bltoolkit?

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

AVK>У меня тут тоже сценарий есть. Каким образом я могу, используя твои теории его осуществить?

AVK>Какое отношение твой сценарий имеет к сопряганию linq и bltoolkit?
Просто интересно выживаемость BLToolkit после выхода 3.0. Штука, хорошая, реализация прекрасная, но на фоне DLink у него преимуществ нет(разве что он более менее свободен от недостатков DLink). Будет обидно если повторится путь R#.

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

GZ>Просто интересно выживаемость BLToolkit после выхода 3.0.

С таким же успехом можно спросить о выживаемости любого ORM после выхода 3.0.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>С таким же успехом можно спросить о выживаемости любого ORM после выхода 3.0.
А ты думаешь он такой уж идеальный?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>BLToolkit — это не ORM, это DataAccess + Mapper.
Честно говоря — в принципе DataAccess+Mapper это и есть ORMapper. В принципе любой DAL слой имеющий на выходе entities или полноценные объекты с поведением сами догружаются — являются ORM.
IT>Вещи независимые, которые вполне могут использоваться отдельно. Делать из этих заготовок свою собственную ORM или не делать — это уже дело разработчика.
Ага. BLToolkit по функциональности похож на IBatis. Он также разделен. И вроде никто не утверждал что это не ORM.
IT>У меня, например, ни на одном проекте не получалось на 100% использовать одну и туже схему. На каждом проекте что-то своё. Как правило для WebForms и WinForms модели получаются совершенно разные. Где-то нужен глобальный кешь, где-то локальный, где-то pure stateless. Каждый раз я подстраиваю BLToolkit под задачу. В случае с ORM всё наоборот. Я вынужден задачу подстраивать под ORM.
Во-первых не все ORM имеют кэш. И я бы сказал, что кэш это не из пререгатива. То что иногда называют кэшем всего лишь средство для поддержания консистентности транзакций(я видел термин более подходящий для него, lifetime tracking).
Во вторых, нужно всегда все подстраивать, к языку программирования, к используемому framework и т.д. Только при этом стараться не подстраивать базу данных, а подстраивать архитектуру самого приложения. Благо подстройка БД — более криминальный процесс в плане производительности.
В третьих, я начинаю понимать что вы имели ввиду. ORM бывают двух типов. Один тип, это когда на выходе у тебя полноценный объект с полноценным поведением, второй тип — это когда на выходе entities(не могу подобрать правильный термин) который в свою очередь также является типизированнам классом. В любом случае они являются ORM поскольку занимаются тем, что являются некоторой прокладкой для прозрачного получения типизированных объектов из реляционной модели. Hibernate — имеет тенденции первого класса, BLToolkit и DLink — это тенденции второго класса. Разделить из полностью нельзя, потому как можно использовать как для того, так и другого.(о термине реляционно-объектного маппинга я вообще услышал впервые)

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>>С таким же успехом можно спросить о выживаемости любого ORM после выхода 3.0.
GZ>А ты думаешь он такой уж идеальный?

Я его ещё толком не смотрел. Видел только на лаптопе у AVK и знаю о Linq с его же слов, которые произносились в основном между предыдущей и следующей стопочкой кеттел вана

Так что судить пока рано.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>

Я его ещё толком не смотрел.
Я тоже только документы его читал времен PDC. Крепкая вещь, только ничего на свете не бывает без недостатков. Надо будет скачать да ручками попробывать(не знаю, есть ли версия, та была для беты2).
IT>Видел только на лаптопе у AVK и знаю о Linq с его же слов, которые произносились в основном между предыдущей и следующей стопочкой кеттел вана

Буржуины, блин.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>>Видел только на лаптопе у AVK и знаю о Linq с его же слов, которые произносились в основном между предыдущей и следующей стопочкой кеттел вана

GZ>Буржуины, блин.

Так заезжай, обсудим ORM vs вселенная. Кеттел ван и солёные огурчики с меня

... << RSDN@Home 1.2.0 alpha rev. 0>>

IT wrote:
> GZ>И кстати, не забывай. BLToolkit точно такая же ORM как и другие.
> Просто сильно недоделанная. Она делает абсолютно то же самое что и
> другие. Просто и типовых шаблонов как таковых раз-два и обчелся, поэтому
> ест тенденция работы прямыми вызовами, и дополнительных инструментов мало.
> BLToolkit — это не ORM, это DataAccess + Mapper. Вещи независимые,
> которые вполне могут использоваться отдельно.
А чем BLToolkit лучше iBatis.NET?

Posted via RSDN NNTP Server 2.0

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

C>А чем BLToolkit лучше iBatis.NET?

Думаю, что у iBatis.NET (кстати, а что это такое?) есть как минимум один фатальный недостаток.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

C>>А чем BLToolkit лучше iBatis.NET?

IT>Думаю, что у iBatis.NET (кстати, а что это такое?)

возможно это

IT>есть как минимум один фатальный недостаток.

этот баг неистребим.

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

C>А чем BLToolkit лучше iBatis.NET?
А кто сказал лучше? Он другой. Он более основан на xml.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>Так заезжай, обсудим ORM vs вселенная.
Не раньше чем годика через два.

IT>Кеттел ван и солёные огурчики с меня

Местный первач? С удовольствием.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>>Думаю, что у iBatis.NET (кстати, а что это такое?)

V>возможно это

Судя по описанию, это лишь небольшая часть BLToolkit. Впрочем, спасибо за ссылочку, надо будет оттуда что-нибудь стырить

IT>>есть как минимум один фатальный недостаток.

V>

этот баг неистребим.

На самом деле, когда начинался делаться BLToolkit, точнее тогда ещё RFD, в 2002 году, то никаких подобных вещей, даже портов с джавы ещё не было. Это уже потом всякие ORM начали расти как грибы.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>Судя по описанию, это лишь небольшая часть BLToolkit. Впрочем, спасибо за ссылочку, надо будет оттуда что-нибудь стырить

У нас тут люди говорят, что iBatis'е намного больше функциональности, чем в BLToolkit.

IT>

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

IT>>Судя по описанию, это лишь небольшая часть BLToolkit. Впрочем, спасибо за ссылочку, надо будет оттуда что-нибудь стырить

C>У нас тут люди говорят, что iBatis'е намного больше функциональности, чем в BLToolkit.

В плане DataManager и Mapping? Возможно. Поэтому я и говорю, что надо будет там чего-нибудь потырить. Но BLToolkit этими двумя вещами не заканчивается.

IT>>

На Java писать мне тогда релиния не позволяла.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

GZ>Да похоже на то, что плохо занимались.
Поверь, не плохо...

GZ> Проблемы ясны, опубликованы, и много раз обговорены.
Это не проблемы, это как верно заметил Игорь, следствия...

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

GZ> Или сознательно принижать(или не упоминать) в рекламных целях(а он как ты заметил теперь работает в Microsoft) функциональность современных серьезных ORM систем.
Свое мнение ом ORM он высазывал задолго до того как перешел в MS, и он вообщем-то в своем мнении не одинок.

GZ> поэтому я предположил что г-н Clemens Vasters просто не в теме современных ORM систем.

GZ>Есть задачи которым не подходит ORM. Это то в чем я абсолютно согласен и могу подписаться под любым документом.
Ну вот и договорились..

GZ> Но то, что написал г-н Clemens Vasters не выдерживает критики.
А где критика? Я не увидел в этом топике ни слова критики аргументации гн-а. Вастерса... Ты почему-то какие-то куски из текста выдираешь, делаешь свои выводы и с ними споришь...

GZ>Собственно ты сам мне не возразил ни по одному пункту в предыдущем посте. Интересно почему?
Ну вот потому и не возразил, какой смысл спорить с догадками?...

GZ>Итак, ты никак конструктивно не возразил моей критике,
Как это не конструкивно? Помоему все очень конструктивно...

GZ>давай-ка попробуй возразить следующим утверждениям.
Зачем? То есть мне даже есть что возразить, просто сейчас нет ни времени, ни желания.. Может позже.

GZ>Да ничему он тебя не обязывает.

Увы, обязывает...

GZ>Янус держит много баз данных(а не эту поделку).

Правда? Он держит джет и почти держит сиквел, но только у энтузиастов... Мы вот позавчера с АВК, пока в лондон летели, как раз обсуждали, что надо бы янусе забить на все БД, и написать свой однопользовательский движек для хранения сообщений, потому как достал уже этот зоопарк.

M>>манипуляции кластерными индексами, которым в оракле адекватной замены нет,
GZ>Это еще почему?

Потому что нету.

GZ> Поклеп. Там все мощнее.
Хре... Фигушки.

GZ> Ты можешь держать таблицу отсортированной по любому индексу а не только по primary.
Кто тебе сказал, что в сиквеле можно держать таблицу отсортированную только по Primary? Вот это точно поклеп, более того в сиквеле создавать кластерный индекс по Primary — не рекомендуется. А вот в Оракле ты обязан делать Index Organized Table только по уникальному полю.

GZ> Перевести?
"Не смотря та то что платформы сильно развились за последние семь лет, фундаментальные задачи стоящие перед прозрачными (полностью абстрактными) мапперами данных на объекты, остаются в сущности теми же самыми." (далее идет перечисление проблем стоящих перед ORM, то есть тех проблем, которые ORM должен решать).
Вообще, вчера Клеменс сказал нам, что с очень хорошей вероятностью он в ближайшее время приедет в москву, во время WCF-тура, вот можешь сам у него и спросить.

M>>Не надоело?
GZ>Уже да.
Ну вот и замечательно.

... [RSDN@Home 1.2.0 alpha rev. 619]

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

AVK>>Какое отношение твой сценарий имеет к сопряганию linq и bltoolkit?
GZ>Просто интересно выживаемость BLToolkit после выхода 3.0.

Нормально. Они пересекаются по функционалу не на 100 и даже не на 90%. Если же поддержка LINQ в BLT будет реализована, то вобще все будет прекрасно.

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

AVK>Нормально. Они пересекаются по функционалу не на 100 и даже не на 90%.
Они пересекаются с DLINQ+ LINQ. И притом, для BLToolkit пересечение 100%.

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

GZ>Честно говоря — в принципе DataAccess+Mapper это и есть ORMapper. В принципе любой DAL слой имеющий на выходе entities или полноценные объекты с поведением сами догружаются — являются ORM.

Вот только в BLToolkit ничего само не догружается.

GZ>В третьих, я начинаю понимать что вы имели ввиду. ORM бывают двух типов. Один тип, это когда на выходе у тебя полноценный объект с полноценным поведением, второй тип — это когда на выходе entities(не могу подобрать правильный термин) который в свою очередь также является типизированнам классом. В любом случае они являются ORM поскольку занимаются тем, что являются некоторой прокладкой для прозрачного получения типизированных объектов из реляционной модели. Hibernate — имеет тенденции первого класса, BLToolkit и DLink — это тенденции второго класса.

Нет в DLInQ никаких entities. Результатом последней операции (не считая группировок и вложенных запросов это проекция) являются анолнимные типы, конструируемые под конкретную операцию проекции.

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

AVK>>Нормально. Они пересекаются по функционалу не на 100 и даже не на 90%.
GZ>Они пересекаются с DLINQ+ LINQ

С LINQ BLToolkit вобще не пересекается, а касательно DLINQ — как раз к нему и относилась моя предыдущая фраза.

GZ>. И притом, для BLToolkit пересечение 100%.

Могу лишь предположить что ты плохо знаешь либо одно, либо другое, либо оба сразу. Это чтобы не предположить что то более обидное

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

GZ>>Честно говоря — в принципе DataAccess+Mapper это и есть ORMapper. В принципе любой DAL слой имеющий на выходе entities или полноценные объекты с поведением сами догружаются — являются ORM.

AVK>Вот только в BLToolkit ничего само не догружается.
Значит это больше похоже на тип 1(entities).

AVK>Нет в DLInQ никаких entities. Результатом последней операции (не считая группировок и вложенных запросов это проекция) являются анолнимные типы, конструируемые под конкретную операцию проекции.
Эээ нет. Может я немного устарел, и размышляю на основе DLinq который выходил к PDC, но именно проекция там, это совершенно отдельная операция. И если воспользоваться проекцией, то этот объект уже не отслеживается Lifetime Tracking и не апдейтится(хотя возможно он может быть сохранен через интеграцию store procedure, не знаю). Это очень похоже на ситуацию с вьюхами. После выборки, нельзя сохранить измененный результат(если не брать в рассчет INSTEAD OF). В случае если возвращать неизмененный объект, то его можно автоматизированно сохранять.
Что касается entities, то насколько я помню, они сами себя так позиционировали.

Ты их в этом будешь обвинять?

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

GZ>>. И притом, для BLToolkit пересечение 100%.

AVK>Могу лишь предположить что ты плохо знаешь либо одно, либо другое, либо оба сразу. Это чтобы не предположить что то более обидное

Ближе к телу как говорил Мопасан. Где именно DLink не поддерживает такую же функциональность BLToolkit?

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

AVK>>Могу лишь предположить что ты плохо знаешь либо одно, либо другое, либо оба сразу. Это чтобы не предположить что то более обидное

GZ>Ближе к телу как говорил Мопасан. Где именно DLink не поддерживает такую же функциональность BLToolkit?

Validation, ObjectBinder, абстрактный DataAccessor, Emit с человеческим лицом, TypeAccessor (кстати, как насчёт скорости у DLink?), всякие имплы, EditableObjects, на подходе аспекты, расширяемый атрибутами TypeBuilder.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

Специально себе нашел документуху на DLink от PDC.
IT>Validation,
Легко, через см аттрибуты UpdateMethodAttribute, InsertMethodAttributeб DeleteMethodAttribute. Правда сейчас нет твоих сырцов посмотреть что это такое, но в принципе — это не проблема DAL слоя. Это в большей степени проблема бизнес логики.
IT>ObjectBinder,
На фиг?

Стандартный List он и в Африке стандартный List. Объекты внутри типизированные. Хотя у низ во фьючах стоит что будут делать еще DataBinding(у меня версия от PDC).
IT>абстрактный DataAccessor,
Другая система. Он в подобном DataAccesor не нуждается. Там есть DataContext, все можно через него + Standart Query Language.
IT>Emit с человеческим лицом,
Это к делу не относится.
IT>TypeAccessor (кстати, как насчёт скорости у DLink?),
Не нужен. В компилятор вделали анонимные типы(что позволено им, не позволено нам). С ними можно работать без дополнительных Accessor'ов. Типа:

var q =
    from c in Customers
    where c.City == "London"
    select c;
foreach (var cust in q)
    Console.WriteLine("id = {0}, City = {1}", cust.CustomerID, cust.City);

IT>всякие имплы, EditableObjects,
Поясни что это такое.
IT>на подходе аспекты, расширяемый атрибутами TypeBuilder.
А вот это особенно интересно. Поясни. Видел код но еще не разбирался что за фенька.

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

IT>>Validation,
GZ>но в принципе — это не проблема DAL слоя. Это в большей степени проблема бизнес логики.

Совершенно верно. Это не проблема DAL слоя. Тем не менее что можно ответить на твой вопрос?

Где именно DLink не поддерживает такую же функциональность BLToolkit?

IT>>ObjectBinder,
GZ>На фиг?

Стандартный List он и в Африке стандартный List.

Стандартный не пойдёт, нужен как минимум ITypedList для WinForms. Во втором фреймворке MS кое что сделала, так что можно условно (очень условно) сказать, что кое что есть. Для WebForms примерно также. Баиндинг как бы есть, но кастрированный и через рефлекшин.

GZ> Объекты внутри типизированные. Хотя у низ во фьючах стоит что будут делать еще DataBinding(у меня версия от PDC).

Интересно будет глянуть.

IT>>абстрактный DataAccessor,
GZ>Другая система. Он в подобном DataAccesor не нуждается. Там есть DataContext, все можно через него + Standart Query Language.

Что можно через него? Можно ограничится одним описанием метода и он будет ассоциирован с сохранённой процедурой?

IT>>Emit с человеческим лицом,
GZ>Это к делу не относится.

См. п. 1.

IT>>TypeAccessor (кстати, как насчёт скорости у DLink?),
GZ>Не нужен. В компилятор вделали анонимные типы(что позволено им, не позволено нам). С ними можно работать без дополнительных Accessor'ов. Типа:

А что ты будешь дальше с ними делать? Как баиндить на формы, как использовать в своей бизнес логике?

IT>>всякие имплы, EditableObjects,
GZ>Поясни что это такое.

Объекты, у которых есть методы вроде AcceptChanges, Rejecthanges, флаг IsDirty и пр.

IT>>на подходе аспекты, расширяемый атрибутами TypeBuilder.
GZ>А вот это особенно интересно. Поясни. Видел код но еще не разбирался что за фенька.

Речь о догенерировании виртуальных методов. Кто-то тут приводил аналогичную штуку в яве.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>>>Validation,
GZ>>но в принципе — это не проблема DAL слоя. Это в большей степени проблема бизнес логики.

IT>Совершенно верно. Это не проблема DAL слоя. Тем не менее что можно ответить на твой вопрос?

IT>

IT>Где именно DLink не поддерживает такую же функциональность BLToolkit?

Но в принципе она легко реализуемая через DataContext(о чем я и говорил до этого и показано в параграфе про процедуры).

GZ>> Объекты внутри типизированные. Хотя у низ во фьючах стоит что будут делать еще DataBinding(у меня версия от PDC).
IT>Интересно будет глянуть.
Мне интересно будет глянуть, там у них во фьючах объявлена лучшая поддержка Multi-tier Applications and Web Services. Что они под этим подразумевают.

IT>>>абстрактный DataAccessor,
GZ>>Другая система. Он в подобном DataAccesor не нужда ется. Там есть DataContext, все можно через него + Standart Query Language.
IT>Что можно через него? Можно ограничится одним описанием метода и он будет ассоциирован с сохранённой процедурой?
И так, и так. По маппингу может генерить сам команды, или можно сделать так:

public partial class Northwind : DataContext
{
    ...
    [UpdateMethod]
    public void OnProductUpdate(Product original, Product current) {
        // Execute the stored procedure for UnitsInStock update
        if (original.UnitsInStock != current.UnitsInStock) {
            int rowCount = this.ExecuteCommand(
                "exec UpdateProductStock " +
                "@id={0}, @originalUnits={1}, @decrement={2}",
                original.ProductID,
                original.UnitsInStock,
                (original.UnitsInStock - current.UnitsInStock)
            );
            if (rowCount < 1)
                throw new OptimisticConcurrencyException();
        }
        ...
    }
}

IT>>>Emit с человеческим лицом,
GZ>>Это к делу не относится.
IT>См. п. 1.
См. параграф про анонимные типы и local type inference ниже.

IT>А что ты будешь дальше с ними делать? Как баиндить на формы, как использовать в своей бизнес логике?
Это некоторый промежуточный вариант(до нормального type inference ему далеко). Можно сделать и так:

var q =
    from c in db.Customers
    where c.City == "London"
    select c;
// Execute once using ToList() or ToArray()
var list = q.ToList();
foreach (Customer c in list)
    Console.WriteLine(c.CompanyName);

Можно вообще использовать Projection:

var q =
    from c in db.Customers
    where c.City == “London”
    select new MyType(c.ContactName, c.Phone) into x
    orderby x.Name
    select x;

Но в этом случае весь update только вручную.

IT>>>всякие имплы, EditableObjects,
GZ>>Поясни что это такое.
IT>Объекты, у которых есть методы вроде AcceptChanges, Rejecthanges, флаг IsDirty и пр.
Есть в автоматическом режиме для Lifetime Tracking. Причем транзакционность может идти как по версиям, так и по состоянию. При Rollback он вместо убийства объектов будет подставлять старое дотранзакционное состояние. Такая шняга прекрасно подходит как для систем с stateless, так и statefull.

IT>Речь о догенерировании виртуальных методов. Кто-то тут приводил аналогичную штуку в яве.

Существует несколько вопросов по генерации запросов, но как-то озвучивать их пока я не могу.(придет RSDN 5, там вроде новая версия, надо будет поюзать, только тогда можно будет хоть что-то сказать)

От:	Merle	http://rsdn.ru
Дата:	21.03.06 08:36
Оценка:	43 (2)

	От:	Cyberax
	Дата:	22.03.06 03:49
	Оценка:	10 (2)

От:	IT	linq2db.com
Дата:	22.03.06 13:17
Оценка:	+2

От:	IT	linq2db.com
Дата:	25.03.06 17:07
Оценка:	+2

От:	Merle	http://rsdn.ru
Дата:	21.03.06 18:28
Оценка:	2 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	22.03.06 12:44
Оценка: