Научите меня быть умным! (.NET) Отсоединенное соединение.

← →
Курдль © (2004-06-04 09:20) [0]

...или отключенное подключение :)
На самом деле вопрос очень важный! Ведь при переходе на Delphi 8 и технологию .NET возникает крушение стереотипов!
Видимо придется проститься со старыми принципами подключения к БД. Например, как раньше, - открыть приложение, совершить типа DataBase.Connection.Open, поработать и в конце дня сделать DataBase.Connection.Close - непозволительная роскошь!
Вот и вопрос. Кто может поделиться материалами, ссылками, опытом по созданию проектов .NET в части касающейся работы с Connection-ами?

← →
Polevi © (2004-06-04 09:40) [1]

там все просто с коннекшнами

открыли
выбрали данные
закрыли

работаем с данными

открыли
запостили изменения
закрыли

← →
Курдль © (2004-06-04 09:49) [2]

А существуют ли рекомендации лучших собаководов типа "MS настоятельно советует делать так:..."
Мне надо по максимуму аргументировать!

← →
Mike_Goblin © (2004-06-04 09:53) [3]

существует документация и примеры
PS все гораздо хуже
создали объект соединения, подключились, получили/отправили данные, отключились, убиди объект.

← →
Курдль © (2004-06-04 10:05) [4]

> Mike_Goblin © (04.06.04 09:53) [3]
> существует документация и примеры

Пожалуйста! Любую ссыдку - хоть на книжки, хоть по авторам!
А то вся литература весьма поверхностна и чаще всего повторяется!

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

Это, вроде как, понятно. Но дело в том, что иногда возникает сложная цепочка обновлений, вызываемая разными модулями (формами), но находящаяся внутри одной транзакции.
В то же время, по стилю .NET каждой форме желательно иметь по собственному Connection. Как в таком случае объять всё одной транзакцией?

← →
ZrenBy © (2004-06-04 10:17) [5]

>Курдль ©

Гы. Вспоминается спор о транзакциях :)

← →
Курдль © (2004-06-04 10:19) [6]

> ZrenBy © (04.06.04 10:17) [5]
> >Курдль ©
> Гы. Вспоминается спор о транзакциях :)

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

← →
Polevi © (2004-06-04 10:27) [7]

по стилю .NET каждой форме желательно ..
причем тут формы вообще ? учись отделять данные от их представления
connection динамически создавай

public void UpdateData(String sql)
{
SqlConnection conn=new SqlConnection(ConnString);
try
conn.Open();
SqlTransaction tran=conn.BeginTransaction(IsolationLevel.Serializable);
SqlCommand cmd=new SqlCommand();
cmd.Connection=conn;
cmd.Transaction=tran;
cmd.CommandText=sql;
cmd.ExecuteNonQuery();
tran.Commit();
catch
{
if(tran!=null)
tran.RollBack();
}
finally
conn.Close();
end;
}

и посмотри DataAdapter

← →
Курдль © (2004-06-04 10:52) [8]

В данном случае, как раз, использование транзакции не оправдано.

А отделять данные от их представления не так-то просто.
Ведь идеология делфей въелась намертво! :)

← →
Sergey_Masloff (2004-06-04 13:36) [9]

Курдль © (04.06.04 10:52) [8]
>А отделять данные от их представления не так-то просто.
Да и часто не так-то нужно как это представляется в умных книжках ;-)

← →
Polevi © (2004-06-04 13:37) [10]

>В данном случае, как раз, использование транзакции не оправдано.
это откуда такой вывод последовал интересно

← →
Курдль © (2004-06-04 14:03) [11]

> это откуда такой вывод последовал интересно

Да от того же верблюда, что и TQuery.ExecSQL:
cmd.ExecuteNonQuery(); по умолчанию открывает транзакцию неявно, утверждает ее в случае успеха и откатывает по ошибке.

← →
Polevi © (2004-06-04 14:57) [12]

>по умолчанию открывает транзакцию неявно
не люблю я эти неявно.. по умолчанию
и вам советую

← →
Курдль (2004-06-04 15:02) [13]

> и вам советую

И напрасно!

если есть код
begin a := b; end;то зачем писать
begin begin a := b; end; end;
?

← →
Delirium © (2004-06-04 15:05) [14]

"открыть приложение, совершить типа DataBase.Connection.Open, поработать и в конце дня сделать DataBase.Connection.Close - непозволительная роскошь!" - Гхм, а все ваши существующие win32-приложения постоянно держат коннект с базой? В таком случае настоятельно рекомендую поскорее "крушить стереотипы"! Ибо не правильно сие не только для .Net, но и для любой другой платформы.

← →
Курдль (2004-06-04 15:10) [15]

> а все ваши существующие win32-приложения постоянно держат
> коннект с базой?

А спрогнозируйте-ка поведение данных в связке DBGrid-DataSource-DataSet-DataBase, если кому-то из последних сделать close?

← →
Delirium © (2004-06-04 15:16) [16]

Вы меня не понимаете я вижу, сама связка "DBGrid-DataSource-DataSet-DataBase", уже порочна. Нельзя превращать приложение в on-line редактор для БД. Так делают лишь для локальных DBF-таблиц, да и то редко. Использование ADO в том числе и старого, подразумевает толстого клиента, собственно для и этого и придуман "ADODB.Recordset" - для возможности "отвязаться" от сервера.

← →
Polevi © (2004-06-04 15:17) [17]

> [15] Курдль (04.06.04 15:10)
это зависит от датасета

> и вам советую
>И напрасно!
если вы знаете все лучше всех, зачем задвать вопросы в форуме, учитель ?

← →
Delirium © (2004-06-04 15:24) [18]

По поводу литературы:http://www.gotdotnet.ru/LearnDotNet/ADONET/default.aspx
читайте, учитесь, не спешите воспринимать свои личные подходы как истину последней инстанции.

← →
Курдль (2004-06-04 15:35) [19]

> Вы меня не понимаете я вижу, сама связка "DBGrid-DataSource-DataSet-DataBase",
> уже порочна. Нельзя превращать приложение в on-line редактор
> для БД. Так делают лишь для локальных DBF-таблиц, да и то
> редко. Использование ADO в том числе и старого, подразумевает
> толстого клиента, собственно для и этого и придуман "ADODB.Recordset"
> - для возможности "отвязаться" от сервера.

1. Указанную связку я привел, как наиболее наглядную.
2. Использование ADO было отвергнуто нами пару лет назад, как крайне неудобное и опасное. Надеюсь, что в ADO.NET исправят.
3. Компоненты "Direct Oracle Access" или "SQL Direct" (наиболее профессиональные из всех, что существуют для Delphi) предполагают именно работу с открытым коннектом.

← →
Polevi © (2004-06-04 16:04) [20]

>как крайне неудобное и опасное
можно поподробнее

← →
Delirium © (2004-06-04 16:21) [21]

"Использование ADO было отвергнуто нами пару лет назад, как крайне неудобное и опасное" - ну насмешил :) Не могу не тыкать клоуну, считающему себя умнее идеологов Miicrosoft.

← →
Delirium © (2004-06-04 16:28) [22]

Написал бы честно: "Не умею работать с ADO, учиться - лень, взял что попало под руку и стал ваять, а теперь, когда софта наворочал - переходить тяжело", а то - "наиболее профессиональные"! Т.е. типа в состоянии оценить профессианолизм решения, а вот научиться ADO пользоваться по человечески - не можешь.

← →
Курдль (2004-06-04 22:01) [23]

> Не могу не тыкать клоуну, считающему себя умнее идеологов
> Miicrosoft.

А Вы не идеолог, случаем? Им всегда было очень легко, как например идеологам отечественного автомобилестроения :)
Дело не в идеологах, а в реализаторах от Борланда!
Если, конечно, делать программы - записные книжки или тесты для школы, то можно и не подозревать, зачем у профессиональных датасэтов есть свойство "OnApplyRecord", которого нет у ADO, как и многих других.

← →
Sergey Masloff (2004-06-04 22:53) [24]

Delirium © (04.06.04 15:16) [16]
>для возможности "отвязаться" от сервера.
Да только не всегда это нужно. В смысле отвязываться. Есть какие-то доводы в пользу этого решения кроме рекомендаций "идеологов Майкрософт"? Вернее, доводы, конечно есть но всегда ли они работают?
В случае локальной сети особого смысла в закрытии коннекта нет. Нагрузку он дает только на момент реального обмена данными, ну так и в случае отсоединенного датасета нужно обмен с базой производить - никуда не дется коннект нужен. Так и чего его дергать туда-сюда? Реальная нагрузка от открытого коннекта ничтожна, даже на Win-платформе Oracle не напрягаясь держит полторы-две тысячи коннектов. Минимизировать обмен данными позволяют и другие технологии, те же кэшированные изменения и так далее. Но при высокой интерактивности приложения и когда большинство действий пользователя связаны с обращениям к серверной бизнес-логике то постоянно открытый коннект может быть весьма удобен.
Так что я попросил бы привести пару-тройку наглядных реальных примеров того что отсоединенный рекордсет это единственное возможное решение на все случаи жизни. Только не надо общих слов и ссылок на рекомендации идеологов - эти рекомендации хорошо известны но не всегда их стоит воспринимать как истину в последней инстанции.

← →
Sergey Masloff (2004-06-04 22:58) [25]

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

Впервые слышу об этих хорошо известных рекомендациях...
Мне уже пора на свалку? 8(

← →
Курдль (2004-06-04 23:54) [27]

> Fay © (04.06.04 23:21) [26]
> Впервые слышу об этих хорошо известных рекомендациях...
> Мне уже пора на свалку? 8(

Вам тоже NASA не приходилось автоматизировать? :)))
Это у них Оракл на 8000 коннектов работал еще до появления даже фантазий про ADO :)

> [24] Sergey Masloff (04.06.04 22:53)
>я попросил бы привести пару-тройку наглядных реальных примеров того что >отсоединенный рекордсет..
любая >2 звенная архитектура с stateless объектами

проблема не колве открытх сессий на DB-Serverе, а в колве пользовательских объектов, которые их держат
stateless модель гораздо лучше масштабируется, это не надо доказывать, я надеюсь ?

← →
Sergey Masloff (2004-06-07 21:34) [30]

Polevi © (06.06.04 10:25) [29]
Давайте поконкретнее. Что у вас за пользовательские объекты которые что-то там держат. Открытые на сервере курсоры?
Открытый запрос в режиме CashedUpdates на сервере ничего не держит. Да и без этого режима обычно не держит. Повторю - тысячи таких сессий сервер не особенно напрягают.
Да, в трехзвенной архитектуре отсоединенные датасеты имеют смысл, в двухзвенке обычно-нет. Так как усложнение разработки и отладки, медленнее работа а реальных преимуществ - не особо-то видно...

> Открытый запрос в режиме CashedUpdates на сервере ничего не
> держит
Ну курсор-то все он ж держит, хотя бы потому, что его могли "недофетчить" еще. Но это вопрос реализации. В идеале после выборки последней записи курсор можно было бы спокойно закрывать (на уровне OCI, и, соответственно, на сервере).

Но если за Connection на самом деле стоят реальные хендлы и при открытии/закрытии оно все время логинится/отсоединяется - ну тогда фьюююююю - идеологи или грибов плохих поели, или не видят другого способа заставить покупать больше процессоров и памяти.
Если же Connection просто закрывает курсор - ну тогда очень правильно делает.

← →
Курдль (2004-06-07 23:58) [32]

> Но если за Connection на самом деле стоят реальные хендлы
> и при открытии/закрытии оно все время логинится/отсоединяется
> - ну тогда фьюююююю - идеологи или грибов плохих поели,
> или не видят другого способа заставить покупать больше процессоров
> и памяти.

Мои наблюдения со стороны сервера показали:
При "Cache Authentication=True" при каждом коннекте из текущего приложения на сервере регистрируется новое соединение с уникальным идентификатором. Ради интереса открывал 10 соединений - все 10 показались на сервере.
При дисконнекте всех соединений одно все равно остается висеть до тех пор, пока не закрывается приложение.
При "Cache Authentication=False" при последнем дисконнекте все соединения тухнут.

> все 10 показались на сервере.
> Научите меня быть умным! (.NET)
Ну тогда такую умность скажу:
Либо - в лучшем случае - Вы просто еще не научились работать с Connection`ами, и все не так плохо.
Либо плюньте на это, потому как по 10 соединений будут открывать все программы, не только Ваша :)

> (.NET)
Организованной толпой
Коровы шли на водопой
Попить воды Бу-бу-бу-бу
По-ть с кусты Бу-бу-бу-бум
:)

> по 10 соединений будут открывать
в смысле пересоединяться на каждый чих

> Либо - в лучшем случае - Вы просто еще не научились работать
> с Connection`ами, и все не так плохо.

У меня несколько книг + инетовские примеры + визард VS по созданию дата-форм. И везде технология одинакова.
Откуда растут ноги - понятно. MS решил завалить Линукса, прикрыть SUN Java и навредить Ораклу посредством унификации подхода программирования доступа к данным. Естественно, при интернет-коннекте есть смысл отключаться как можно быстрее (т.е. проводить физический дисконнект). Это проецируется и на работу виндоуз-приложений.

Научите меня быть умным! (.NET) Отсоединенное соединение. Найти похожие ветки