"Max Rezanov" ...
Большинство я так понял сидит в двух звеной архитектуре и самой точно
характеристикой я выбрал бы "У меня на каждой форме своя транзакция"
Это глупый подход
или у меня в программе 2 транзакции одна читающая на всю жизнь и
длиная, а одна(N) коротких пишущих. Вам дали такую возможность и вы ее
на всю используете
К хорошему привыкаешь :) А вам вот не дали такую возможность и вы её
и у нас забрать хотите, в крайнем случае - идиотами выставить (не о тебе речь,
есс-но :)
и тоже не хотите видеть остального.
Обижаешь
Тотже TClientDataSet тоже упоминался в этой ветке, а никто не думал
зачем его борланд придумал?
Пусть борланд думает ;) А лучше - баги пусть в нём правят. А ещё лучше -
пусть исходники с остальной VCL поставляют.
А кроме 2-х звеных приложений есть другие архитектуры.
Раскажите мне применение даной возможности в веб приложении?
а в трехвеном приложении?
Создать синглетон с подключением и забирать с него
транзакции? мне не кажеться это хорошей мыслью :(.
Бывает такая хрень, как приложение с многослойной архитектурой. Где
каждый слой по-максимуму изолирован от других. Соединение с БД
устанавливается в одном слое, но использоваться может и в других - ничего
необычного, не так ли ? Так вот, другим слоям не положено знать деталей
установки соединения - логин\пароль\имя сервера\и т.д. - изоляция рулит.
Дальше продолжать ?
На rsdn кто-то приводил пример с принтером. Пусть в сервере приложений
это не актуально. Тогда приведём другую задачу - рассылка событий с
подтверждением получени и логированием. В одном коннекте одна тр-ция
читает список событий, а другая - записывает статус отправлен\подтверждён
в БД по мере отправки этих событий. На кой тут второй коннект ? Или кешировать
всё на клиенте ? Тогда как же та самая масштабируемость (а любой кеш - это
ресурсы, а в случае с .net ещё и отложенные проблемы со сборщиком мусора) ?
Или задача надуманная ?
Тут Дед меня обзывал прагматиком, да я такой :)
А ты сколько лицензированных подключений имеешь ? Не считал ? А
прагматики считают и их "там" большинство.
Да мы сечас сидим на C#, трех звеной архитектуре, ADO.NET и оракле.
Я не чуствую себя ущербныи из-за того что у меня одна транзакция на
соединение и пул подключений на сервере приложений.
Потому что всё вышеперечисленное сделано так, чтобы те, кто этим
пользуется, вообще не думали о том "что у нея унутре" - как следствие они
"не хотят видеть остального" - того, на что это прокрустово ложе не рассчитано.
А рассчитывалось оно далеко не на IB\FB.
Это более-менее хорошо работает в массовых поделках, коих 99%, но
уже не так хорошо (по сравнению с) в действительно сложных задачах.
Простота - это хорошо, я не спорю. Но не в ущерб эффективности там,
где она критична. Да и решение с параллельными тр-циями не страдает
особой сложностью :)
--
Хорсун Влад
