Re[7]: Оформление работы с БД в корпоративных приложениях - - Архитектура программного обеспечения

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

C>>Оптимистическое версирование — и никаких проблем (нуу... почти). Пусть держат сколько угодно — объекты блокироваться не будут.
S>Ага, зато будет расти сегмент отката. Не, управление транзакцией с клиента суть вещь противуестественная.
Не будет

Если использовать версирование на уровне приложения (тупо ввести в объекты поле "версия").

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

C>>Всякие гадости типа исчерпания пулов из-за глючных клиентов — тоже можно при желании обрабатывать.
S>То-то и оно, что это приводит к нестабильности и риску DOS на ровном месте.
Естественно, надо хорошо все продумать.

S>В частном случае вменяемого разработчика в SQL отъезжают только атомарные батчи:
S>

S>begin tran 
S>--do smth
S>--do smth else
S>commit tran
S>

S>Никаких открытых транзакций оставаться не должно.
ОЧЕНЬ редкая ситуация в правильных программах — такой подход небезопасен. Придется сначала прочитать объекты, с которыми ты будешь работать, потом сформировать пачку, а только потом отправить на сервер. Это все в разных транзакциях — а значит будет местом для race'ов. Можно бы использовать оптимистическое версирование на уровне приложения, но в SQL достаточно сложно дать гарантию, что оно будет правильно использовано тупыми пользователями API.

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

Так что utm.begin()/работаем/utm.commit() — может оказаться существенно лучше.

C>>Отсылать куски скрипта на каком-нибудь языке? На сервере — посадить этот скрипт в домен с максимально обрезаными правами.
S>Да. Для удобства этот язык можно назвать Structured Query Language.
Так его все равно на сервер пихать придется. То есть, давать клиентам модифицировать базу или выполнять принятые от них запросы. Оба варианта мне лично очень не нравятся.

C>>SOAP подразумевает передачу документов и их обработку сервисами. В случае с RPC мы обычно передаем проксики для объектов на сервере и работаем с ними на клиенте. То есть, можно организовать stateful-операции сравнительно малой кровью.
S>Не, "stateful" и "малой кровью" — вещи несовместимые. Задача как раз избавиться от state, т.к. он очень плохо масштабируется (про коммерческие распределенные кэши я в курсе).
Масштабируемые stateful-сервисы можно в большинстве случаев сделать "малой кровью", если забить на failover и тупо сделать так, чтобы клиент на протяжении сессии работал только с одним сервером кластера.

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

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

C>>>Оптимистическое версирование — и никаких проблем (нуу... почти). Пусть держат сколько угодно — объекты блокироваться не будут.
S>>Ага, зато будет расти сегмент отката. Не, управление транзакцией с клиента суть вещь противуестественная.
C>Не будет

Если использовать версирование на уровне приложения (тупо ввести в объекты поле "версия").
Не смеши меня. Если сделать так, то мусор в базе будет копиться вечно! Кто за тебя будет устаревшие версии собирать?
C>А управление транзакциями со стороны пользователя вообще мне очень противоестественным не кажется.
А мне-кажется. Я вообще к клиентам крайне пессимистично отношусь.
и желании обрабатывать.
S>>То-то и оно, что это приводит к нестабильности и риску DOS на ровном месте.
C>Естественно, надо хорошо все продумать.
Зачем? Я, кстати, вообще не могу сходу изобрести способ более-менее уверенно отстреливать негодяев, которые тупо вешаются к тебе и "забывают" закрыть транзакцию.

S>>Никаких открытых транзакций оставаться не должно.
C>ОЧЕНЬ редкая ситуация в правильных программах — такой подход небезопасен. Придется сначала прочитать объекты, с которыми ты будешь работать, потом сформировать пачку, а только потом отправить на сервер.
Почему??? Все чтение происходит в том же батче.
C> Это все в разных транзакциях — а значит будет местом для race'ов.
Ни в коем случае. Иначе нарушаются границы транзакции и кислотность необратимо портится.
C>Можно бы использовать оптимистическое версирование на уровне приложения, но в SQL достаточно сложно дать гарантию, что оно будет правильно использовано тупыми пользователями API.

C>Ну и у нас нет возможности при таком подходе корректно взять объект, принять решение на основе данных в нем, а потом сделать обновление.

C>Так что utm.begin()/работаем/utm.commit() — может оказаться существенно лучше.
Что будет, если во время Работаем на Транстелекоме начнутся сервисные работы? MS SQL, например, мгновенно роллбэкает транзакцию при закрытии соединения. Кто это будет делать в твоем протоколе?

S>>Да. Для удобства этот язык можно назвать Structured Query Language.
C>Так его все равно на сервер пихать придется.
Я об этом и говорю.
C>То есть, давать клиентам модифицировать базу или выполнять принятые от них запросы. Оба варианта мне лично очень не нравятся.
То-то и оно. Хочется и сесть и съесть — т.е. дать клиенту веревку нужной длины, но не настолько, чтоб повесить сервер.

S>>Не, "stateful" и "малой кровью" — вещи несовместимые. Задача как раз избавиться от state, т.к. он очень плохо масштабируется (про коммерческие распределенные кэши я в курсе).
C>Масштабируемые stateful-сервисы можно в большинстве случаев сделать "малой кровью", если забить на failover и тупо сделать так, чтобы клиент на протяжении сессии работал только с одним сервером кластера.
Client affinity конечно хорошо... Но мне лично кажется не вполне оправданным ограничением.

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

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

kuj>>При чем тут запросы, если речь о процедурах. Вы, конечно же, ничего не знаете о синтаксисе того же PL/SQL и как значительно он отличается от T-SQL? PL/SQL значительно мощнее T-SQL, поэтому "downgrade" на T-SQL зачастую задача далеко не тривиальная.

A>Осталось только выяснить зачем переходить с PL/SQL на T-SQL при добавлении столбца в таблицу. kuj вы вообще клинический идиот?

Re[26]: Оформление работы с БД в корпоративных приложениях -

Клинический здесь у нас только Вы. Вам уже 5 или 6 человек хором твердят, что ORM имеет массу неоспоримых преимуществ перед ХП при создании enterprise-приложений, а Вы продолжаете упорствовать, даже не зная толком о ЧЕМ идет речь. Ламеризм хронический.

A>>>по сранению с тестированеим инсталляции в режиме обновления сущие пустяки. Никакие ORM не потмогу написать корректный апдейтер.
kuj>>Плохому танцору яйца мешают.
A>Ещё один мегагениальный комментарий от человека который никогда не занимался поддержкой инсталляций.
Ну уж куда мне до Вашей гениальности... Гениальности человека, который считает, что SQL и T-SQL это одно и то же и думает при этом, что T-SQL это декларативный язык и многое другое, что вижно невооруженным глазом, читая этот топик.

kuj>>тезис 1: хп хорошо потому, что "использование ХП позволяем автоматически тестировать самый низкоуровневый код работы с данными" — false

A>true. И Синклер тебе даже дал ссылку на инструментарий.

Да если бы не Синклер, Вы бы и знать не знали об это инструментарии. Готов поспорить, что Вы его и в глаза не видели. Кроме того, речь о модульном тестировании и как мы выяснили уже с вами ХП не поддаются модульному тестированию.
Так что false, друг мой, false.

kuj>>тезис 2: хп хорошо потому, что "ХП позволяют держать в БД не только данные, но и код управления данными, обеспечивая их целостность (группировку запросов в транзакции и т.п.) на уровне хранения." — запросы в транзакции и с использованием ORM объединяются прекрасно и ORM дают даже более мощную функциональность по управлению транзакциями — false

A>Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.

Скорее Вы не представляете себе как обеспечивается целостность средствами того же Hibernate.

kuj>>тезис 3: хп хорошо потому, что "ХП напротив проще поддерживать" — нетестируемые, нечитабельные, почти не поддающиеся рефакторингу, куда более сильно привязанные к СУБД и конкретной схеме — false

A>Тебе тут несколько человек написало, что у них есть проекты на ХП и они не страдают по этому поводу.

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

kuj>>Совершенно верно. Быть слепым это Ваше личное дело. Только не надо пытаться навязывать другим плоды своего ограниченного мышление, не обремененного знаниями современных технологий в области архитектуры enterprise-приложений и БД.

A>У меня по крайне мере есть мышление, а твои сообщения либо бессмысленны, либо противоречивы.

перлы из коллекции:

1. Re[10]: Оформление работы с БД в корпоративных приложениях -
2. Re[14]: Оформление работы с БД в корпоративных приложениях -
3. Re[8]: Оформление работы с БД в корпоративных приложениях - "Я тебе говорю. Никто в крупном проекте HQL не пользуется, это подходит только для какого-нибудь среднего онлайн-магазина." "A>>Смотря что делают хранимые процедуры. Конечно, если у тебя реализация вида 1запрос-1ХП, то пользы и от ХП мало и от их тестирования.
kuj>В том-то и дело, что хранимая процедура это черный ящик. В отличии от тестирования того же CLR — где можно делать mocking объектов. Вы пишете тест для процедуры, которая в свою очередь вызывает еще 20 процедур. В итоге Ваш тест тестирует не (только) эту процедуру, но и остальные 20. Поэтому для модульного тестирования 1 запрос — 1 ХП это вообще идеальный вариант.

То что ты написал это полный бред. Получается нельзя тестировать методы классов вызывающие другие методы. Тесты для ХП пишет тот жекто и ХП, для него она не чёрный ящик. А вот тот факт, что ХП чёрный ящик для всех остальных меня радует. Примерно так же как модификатор private. Инкапсуляция... слышал?"
4. Re[10]: Оформление работы с БД в корпоративных приложениях -
"kuj>Ликбез: транзакции выполняются на сервере. Только на сервере. Поэтому нет никакого "лучше" / "хуже".

Мысль что Hibernate и БД могут работать на разных серверах в голову не приходила?"

"kuj>Их сложно писать не "так" в силу синтаксиса и убогости T-SQL.

Ещё один миф. SQL декларативный язык, это уже обеспечивает хорошую читаемость.
"
Во-первых, как видим Вы таки не знаете разницы между T-SQL и SQL, а во-вторых, утверждение, что декларативные языки обеспечивают хорошую читабельности это просто перл среди перлов! Спорим, я могу показать Вам пару декларативных программ, написанных на Prolog и Lisp, которые Вы не сможете прочитать. А ведь это реальные декларативные языки (логики предикатов и функциональный соответственно), а не информационно-логический SQL с декларативными элементами или императивный T-SQL с декларативными элементами...

"kuj>Вот именно. Ваш проект на ХП имеет минимум "защиты от дурака". У нас активно применяется TDD, что фактически не возможно было бы, если бы проект был с использованием ХП.

TDD проверяет корректность работы, а не эффективность."

Абсолютное незнание термина TDD.

5. Re[12]: Оформление работы с БД в корпоративных приложениях -

"Видишь ли, Hibernate как правило наботает в tier бизнесс-логики." это 5 баллов. Незнание архитектуры современных enterprise-систем на лицо.

6. "Re[10]: Оформление работы с БД в корпоративных приложениях -"
опять же незнание принципов модульного тестирования на лицо.

7. Re[8]: Оформление работы с БД в корпоративных приложениях -
"TDD замечательно бывает только на SQL" Это круто. Это 5 баллов.

8. Re[19]: Оформление работы с БД в корпоративных приложениях -
"ручное юнит-тестирование. Еще один замечательный перл в коллекцию.

и в продолжении

Re[19]: Оформление работы с БД в корпоративных приложениях -

"А где я тут сказал юнит-тесты?" — и этот человек обвиняет меня в противоречивости?

Декларативность языка обеспечивает хорошую читабельность? Это 5 баллов.

9. Re[6]: Оформление работы с БД в корпоративных приложениях -
"Именно тот факт, что ORM являясь очень удобными средствами никак не контроллирующим разработчика и приводит к отказу от ORM в действительно крупных проектах. " Еще один перл в копилку.

и т.д. можно продолжать и продолжать...

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

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

S>>у SQL, конечно же, есть свои недостатки. Но, имхо, невредно было бы придумать схему с преимуществами обоих подходов.
C>Может вам стоит на Spring+Hibernate в Java посмотреть?

Там множество этих проблем уже решено.
Есть уже, кстати, порт под .NET и NHibernate — Spring.NET

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

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

A>Кто нибудь кстати рискнул написать свой query object

? Если такие есть было б очень интересно посмотреть код...

Я писал, заточенный на мой круг задач. Но там многое завязано на BLToolkit, так что не думаю, что будет очень интересно. На самом деле пока речь не идёт о полноценной универсальной функциональности, там не так всё сложно.

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

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

A>Кто нибудь кстати рискнул написать свой query object

? Если такие есть было б очень интересно посмотреть код...

А почему бы не взять ейный из того же Hibernate и не переделать под свои нужды, если очень хочется?

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

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

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

S>>>Ага, зато будет расти сегмент отката. Не, управление транзакцией с клиента суть вещь противуестественная.
C>>Не будет

Если использовать версирование на уровне приложения (тупо ввести в объекты поле "версия").
S>Не смеши меня. Если сделать так, то мусор в базе будет копиться вечно! Кто за тебя будет устаревшие версии собирать?
То есть? Я не предлагаю ХРАНИТЬ предидущие версии. Просто добавляешь в объекты поле "версия", которое инкрементируется при каждом обновлении, и при коммите проверяешь, что поле "версия" в базе равно твоему, иначе кидаешь исключение. Тогда не нужно никаких больших сегментов отката.

S>>>То-то и оно, что это приводит к нестабильности и риску DOS на ровном месте.
C>>Естественно, надо хорошо все продумать.
S>Зачем? Я, кстати, вообще не могу сходу изобрести способ более-менее уверенно отстреливать негодяев, которые тупо вешаются к тебе и "забывают" закрыть транзакцию.
Тупой таймаут и ограничение на N параллельных коннектов. Для длительных операций, которые все-таки не влазят в таймаут, просто делаем специальные отдельные сервисы.

C>>ОЧЕНЬ редкая ситуация в правильных программах — такой подход небезопасен. Придется сначала прочитать объекты, с которыми ты будешь работать, потом сформировать пачку, а только потом отправить на сервер.
S>Почему??? Все чтение происходит в том же батче.
Тогда вся обработка должна быть написана на SQL. Собственно, тогда ВООБЩЕ нет особого смысла выделять бизнес-логику из БД.

C>>Так что utm.begin()/работаем/utm.commit() — может оказаться существенно лучше.
S>Что будет, если во время Работаем на Транстелекоме начнутся сервисные работы? MS SQL, например, мгновенно роллбэкает транзакцию при закрытии соединения. Кто это будет делать в твоем протоколе?
Менеджер транзакций, работающий на сервере. Ему указывается таймаут (который передается в том числе и транзакционным источникам, таким как соединения с БД), по истечение которого — транзакция прибьется. По крайней мере, у меня так и сделано.

Если канал ОЧЕНЬ ненадежный, то возможна ситуация, когда один клиент будет постоянно отваливаться и оставлять соединения умирать по таймауту. Для этого нужно поставить "автокиллер", который будет насильно прибивать предыдущие повисшие транзакции клиента, когда от клиента будут приходить новые запросы.

C>>Масштабируемые stateful-сервисы можно в большинстве случаев сделать "малой кровью", если забить на failover и тупо сделать так, чтобы клиент на протяжении сессии работал только с одним сервером кластера.
S>Client affinity конечно хорошо... Но мне лично кажется не вполне оправданным ограничением.
На практике работает вроде нормально.

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

kuj>>Очень рекомендую Castle Windsor (или MicroKernel) для уменьшения зависимостей.

kuj>>http://www.castleproject.org/container/index.html
K>еще слыхал про NanoContainer (или PicoContainer),
K>в MS CAB используется свой ObjectBuilder.
K>но видимо Windsor проще
Да их приличное множество существует и принципиальных различий междуними не много... Поэтому скорее дело вкуса.

Вот еще хорошая серия статей по Castle Windsor и IoC
http://dotnetslackers.com/articles/designpatterns/InversionOfControlAndDependencyInjectionWithCastleWindsorContainerPart1.aspx

K>помойму вообще лучше всего делать на каком-нить каркасе, типа Spring или Eclipse RCP., там и сразу контейнер интегрирован, и большая часть работы сделана
Совершенно верно.

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

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

Настоятельно советую обоим джентльменам воздержаться от обсуждения квалификации друг друга.
Вы уже успели оба на полугодовой бан наобщаться!
Подходы к разработке можете обсуждать сколько угодно.

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

Здравствуйте, Cyberax, Вы писали:
C>То есть? Я не предлагаю ХРАНИТЬ предидущие версии. Просто добавляешь в объекты поле "версия", которое инкрементируется при каждом обновлении, и при коммите проверяешь, что поле "версия" в базе равно твоему, иначе кидаешь исключение. Тогда не нужно никаких больших сегментов отката.
А, ну то есть optimistic locking. Извини, протупил.
Это тоже не панацея. Будут неизбежные проблемы. Для начала, не удастся воспользоваться встроенной механикой СУБД, придется все изменения накапливать в памяти и откладывать их до коммита. Далее, в стоимость коммита начинает входить повторное чтение всех прочитанных в транзакции данных.
Версионники фактически делают то же самое, только transaction changes хранятся в базе, а не в памяти.
Длина транзакции неизбежно влияет на стоимость

S>>Зачем? Я, кстати, вообще не могу сходу изобрести способ более-менее уверенно отстреливать негодяев, которые тупо вешаются к тебе и "забывают" закрыть транзакцию.
C>Тупой таймаут и ограничение на N параллельных коннектов.
Значит, будет DDoS. Это всё обходится.
C> Для длительных операций, которые все-таки не влазят в таймаут, просто делаем специальные отдельные сервисы.
Вот это меня и беспокоит: то, что мы наворачиваем целую сеть решений только для проблем, которые сами же и создали. Мне бы хотелось, чтобы инфраструктура решала значительно больше проблем, чем создавала бы

C>Тогда вся обработка должна быть написана на SQL. Собственно, тогда ВООБЩЕ нет особого смысла выделять бизнес-логику из БД.
Совершенно верно. В идеале, вместо SQL был бы нормальный язык высокого уровня, который бы не приносил такого страшного performance penalty на не-SQL операциях.
Вообще, курсоры в T-SQL, к примеру, так плохи не потому, что вообще плохи, а потому, что код курсора чудовищно медленно интерпретируется.
Если бы код компилировался в нативную программу, то особой разницы в стейтменте с UDF и курсоре не было бы.

S>>Что будет, если во время Работаем на Транстелекоме начнутся сервисные работы? MS SQL, например, мгновенно роллбэкает транзакцию при закрытии соединения. Кто это будет делать в твоем протоколе?
C>Менеджер транзакций, работающий на сервере. Ему указывается таймаут (который передается в том числе и транзакционным источникам, таким как соединения с БД), по истечение которого — транзакция прибьется. По крайней мере, у меня так и сделано.
Ну, это может быть решением, а может и не быть.

C>Если канал ОЧЕНЬ ненадежный, то возможна ситуация, когда один клиент будет постоянно отваливаться и оставлять соединения умирать по таймауту. Для этого нужно поставить "автокиллер", который будет насильно прибивать предыдущие повисшие транзакции клиента, когда от клиента будут приходить новые запросы.
Хочется чего-то более простого; причем очевидный способ — это именно скармливать запросы целиком. Вот HTTP построен именно по этой схеме, и он прямо-таки фантастически удачен.
S>>Client affinity конечно хорошо... Но мне лично кажется не вполне оправданным ограничением.
C>На практике работает вроде нормально.
У нас тоже есть опыт его эксплуатации. Может быть, я просто отношусь к нему с предубеждением.

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

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

S>А, ну то есть optimistic locking. Извини, протупил.
S>Это тоже не панацея. Будут неизбежные проблемы. Для начала, не удастся воспользоваться встроенной механикой СУБД, придется все изменения накапливать в памяти и откладывать их до коммита.
Да, но обычно это не так уж сильно плохо. Кроме того, в большинстве случаев и так это придется делать.

S>Далее, в стоимость коммита начинает входить повторное чтение всех прочитанных в транзакции данных.
Нет, стандартный прием для версирования: "UPDATE ... SET ... WHERE id=? AND version=?". Если этот оператор вернет 0 (ни одного ряда не обновлено) — то значит у нас оптимистическая ошибка. Можно это сделать и batch'ем для нескольких обновлений.

S>Версионники фактически делают то же самое, только transaction changes хранятся в базе, а не в памяти.
S>Длина транзакции неизбежно влияет на стоимость

Обычно для сервисов нужно минимизировать длину. Кроме того, тут у нас затраты на память будут на стороне клиента, а не сервера. Так что если он решит похулиганить — то ССЗБ.

S>>>Зачем? Я, кстати, вообще не могу сходу изобрести способ более-менее уверенно отстреливать негодяев, которые тупо вешаются к тебе и "забывают" закрыть транзакцию.
C>>Тупой таймаут и ограничение на N параллельных коннектов.
S>Значит, будет DDoS. Это всё обходится.
Так пусть себе DDoSит себя — отъест свои соединия и отвалится. На остальных клиентов влиять не будет.

C>> Для длительных операций, которые все-таки не влазят в таймаут, просто делаем специальные отдельные сервисы.
S>Вот это меня и беспокоит: то, что мы наворачиваем целую сеть решений только для проблем, которые сами же и создали. Мне бы хотелось, чтобы инфраструктура решала значительно больше проблем, чем создавала бы

Так ее надо один раз сделать — и она будет решать. Мы вот себе сделали такую неплохую инфраструктуру, в которой есть фичи, которых нет ни в одном существующем протоколе remoting'а

C>>Тогда вся обработка должна быть написана на SQL. Собственно, тогда ВООБЩЕ нет особого смысла выделять бизнес-логику из БД.
S>Совершенно верно. В идеале, вместо SQL был бы нормальный язык высокого уровня, который бы не приносил такого страшного performance penalty на не-SQL операциях.
Еще он сам по себе слишком жуткий по сравнению даже с VB.

S>Вообще, курсоры в T-SQL, к примеру, так плохи не потому, что вообще плохи, а потому, что код курсора чудовищно медленно интерпретируется.
S>Если бы код компилировался в нативную программу, то особой разницы в стейтменте с UDF и курсоре не было бы.
Ну это возможно, во всяких там DB2 и прочих — там процедуры компилируются в С, а потом и в машинный код.

C>>Если канал ОЧЕНЬ ненадежный, то возможна ситуация, когда один клиент будет постоянно отваливаться и оставлять соединения умирать по таймауту. Для этого нужно поставить "автокиллер", который будет насильно прибивать предыдущие повисшие транзакции клиента, когда от клиента будут приходить новые запросы.
S>Хочется чего-то более простого; причем очевидный способ — это именно скармливать запросы целиком. Вот HTTP построен именно по этой схеме, и он прямо-таки фантастически удачен.
Тогда будет ваша проблема с кучей мелких тривиальных операций. Кстати, и HTTP не так уж удачен для многих задач.

S>>>Client affinity конечно хорошо... Но мне лично кажется не вполне оправданным ограничением.
C>>На практике работает вроде нормально.
S>У нас тоже есть опыт его эксплуатации. Может быть, я просто отношусь к нему с предубеждением.
Мне тоже не нравятся не надежные на 100% решения, но как практический компромис без кластерного кэша — сойдет.

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

kuj>Есть уже, кстати, порт под .NET и NHibernate — Spring.NET

...вполне, ИМХО, приятный и функциональный.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

A>>Ну вообще-то из примера вроде было видно, что группируются таким образом только то, над чем проводятся однотипные операции. Login и Password я не вынес. Во-первых, это ударит по производительности, во-вторых, с ними проводится совсем другой набор операций.
S>Я это веду к тому, что раз уж такие "резиновые" поля так отличаются от "основных", то может иметь смысл отразить это и на уровне апп.сервера. Т.е. так и добавить в Person свойство CustomProperties типа Dictionary<string, object>. Тогда добавление нового свойста не затронет не только БД, но даже и код перекомпилировать не придется!

Ну, собственно, на уровне DAL это так и надо сделать. Если удасться на уровне BL, то совсем здорово. В Presentation по-любому придётся специфически обрабатывать, от этого не убежать.

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

S>Например, есть методы CreateUser, CreateSite, AssignSiteToUser. Эти методы нужны, т.к. вызываются в некоторых бизнес-сценариях. Теперь обнаруживается сценарий, при котором нужно сразу создать пользователя, сайт, и присвоить сайт пользователю. Проблема в том, что если какое-то из действий не пройдет, то нужно откатывать всё. Конечно, можно сделать с клиента цепочку try с обратными действиями в catch:
S>Но это-ненадежная схема, т.к. если в процессе порвется коннект, то Delete*() вызвать не удастся у нас так и останется мусор в сервере.
S>Поэтому мы делаем метод CreateUserWithSite с совершенно тривиальной реализацией.

Ну ещё можно соединение BL<->DAL сделать Stateful (интерфейс BL при этом останется stateless) и ввести DAL-side транзакции. Тогда, скажем, не нужная BL операция DeleteUser не будет присутствовать в интерфейсе DAL, что тоже плюс.

Вызываешь
BeginTransaction()
User user = CreateUser(...)
CreateSite(user)
CommitTransaction()

Транзакции на уровне DAL, учитывая что у тебя будут упорядоченные пары действие-противодействие, конечно всё усложнят, но не геморрой.

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

A>>Осталось только выяснить зачем переходить с PL/SQL на T-SQL при добавлении столбца в таблицу. kuj вы вообще клинический идиот?
kuj>Re[26]: Оформление работы с БД в корпоративных приложениях -

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

A>>true. И Синклер тебе даже дал ссылку на инструментарий.
kuj>Да если бы не Синклер, Вы бы и знать не знали об это инструментарии.

Какое это имеет отношение к наличию или функциональности инструментария? Ты вообще со мной воюешь или против ХП? Определяйся.

A>>Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.
kuj>Скорее Вы не представляете себе как обеспечивается целостность средствами того же Hibernate.

При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.

A>>Тебе тут несколько человек написало, что у них есть проекты на ХП и они не страдают по этому поводу.
kuj>Одно из двух: не страдают, так как не знают что они теряют, либо проекты на очень малы.

Ага, то есть ты готов придумать что угодно, лишь бы не признавать что с ХП можно дружно жить.

A>>У меня по крайне мере есть мышление, а твои сообщения либо бессмысленны, либо противоречивы.
kuj>перлы из коллекции:

kuj>и т.д. можно продолжать и продолжать...

Ага, просто перечислил несколько читат вырванных из контекста. Шикарно. Объяснения почему это так, а не эдак от тебя нет. Толковых ответав нет. Просто регулярно постишь провокационные сообщения на тему "вы не разбираетесь". Пустышка.

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

S>Настоятельно советую обоим джентльменам воздержаться от обсуждения квалификации друг друга.
S>Вы уже успели оба на полугодовой бан наобщаться!
S>Подходы к разработке можете обсуждать сколько угодно.

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

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

A>>>Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.
kuj>>Скорее Вы не представляете себе как обеспечивается целостность средствами того же Hibernate.
A>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
То есть? Если не используем автокоммит — то транзакция в БД, в которой работал Hibernate, просто откатится через некоторое время по таймауту.

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

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

A>>>Осталось только выяснить зачем переходить с PL/SQL на T-SQL при добавлении столбца в таблицу. kuj вы вообще клинический идиот?
kuj>>Re[26]: Оформление работы с БД в корпоративных приложениях -

A>Это другая ветка, ты даже сам не знаешь на что отвечаешь. Что и требовалось доказать.

Не вижу смысла плодить ответы на Ваш бред в разных ветках.

A>>>true. И Синклер тебе даже дал ссылку на инструментарий.
kuj>>Да если бы не Синклер, Вы бы и знать не знали об это инструментарии.

A>Какое это имеет отношение к наличию или функциональности инструментария? Ты вообще со мной воюешь или против ХП? Определяйся.

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

A>>>Ты судя по всему плохо себе представляешь что такое целостность данных в БД с денормализованными таблицами. Ну да ладно, быть дураком личное право каждого.
kuj>>Скорее Вы не представляете себе как обеспечивается целостность средствами того же Hibernate.

A>При обрыве соединения БД<->Hibernate ты никакую целостность средствами Hibernate не обеспечишь. БД останется в несогласованном состоянии.
Кто Вам эту чушь сказал? Еще один пример полной некомпетентности. ликбез: при обрыве связи происходит rollback транзакции.

A>>>Тебе тут несколько человек написало, что у них есть проекты на ХП и они не страдают по этому поводу.
kuj>>Одно из двух: не страдают, так как не знают что они теряют, либо проекты на очень малы.

A>Ага, то есть ты готов придумать что угодно, лишь бы не признавать что с ХП можно дружно жить.

Дружить можете с кем угодно, а нам работать надо.

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

	От:	Aviator
	Дата:	28.09.07 09:59
	Оценка:

	От:	kuj
	Дата:	28.09.07 10:04
	Оценка:

	От:	Cyberax
	Дата:	28.09.07 10:25
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	28.09.07 10:44
Оценка:

	От:	kuj
	Дата:	28.09.07 10:45
	Оценка:

От:	Нахлобуч	https://hglabhq.com
Дата:	28.09.07 12:29
Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	28.09.07 13:44
Оценка:	-1