Ega23 ©   (15.01.09 12:30) [38]
Медвежонок Пятачок ©   (15.01.09 12:46) [39]

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

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

Медвежонок Пятачок ©   (15.01.09 12:55) [41]


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


Ключевое слово в моем посте - к уже открытому (нужным образом отфильтрованному, отсортированному и т.п.)
Ты предлагаешь в этом случае делать клон, применять все те же критерии выборки и работать с клоном ?

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


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

to Игорь Шевченко ©   (15.01.09 12:52) [40]:
>А если к конкретному датасету потребуется обратиться из другой
>(возможно невизуальной) части проекта ?
>(причем, к уже открытому)
Передать туда датасет через параметр никто не запрещал. Но, честно говоря, я не припомню, чтобы такое когда-либо понадобилось.

> vuk ©   (15.01.09 12:12) [37]
>
> У нас в проектах не принято выносить объекты данных в датамодули.
>


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

Ключевое слово в моем посте - к уже открытому (нужным образом отфильтрованному, отсортированному и т.п.)
Ты предлагаешь в этом случае делать клон, применять все те же критерии выборки и работать с клоном ?

А понял.
У меня если честно нет таких проблем.
Поясняю.
Допустим есть грид, в котором юзер ввел свои условия фильтрации и сортировки. Набор данных готов для обработки.
Что я делаю в этом случае?

Мой грид имеет волшебный метод :

function BatchProcess(ACallBack : TBlaBlaBlaCallBack; AUserData : Pointer; AWholeDataSet : boolean = False) : integer;

то есть в невизуальной части проекта есть некий колбак, который обрабатывает все записи, а задача грида перечислить все, или только отобранное. И в тоже время "невизуальный" код не занимается подготовкой нового датасета и ничего не портит в текущем.

В общем такое вот решение.

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

Я к этому пришел довольно быстро.
Унификация другого не дает сделать.

В таком случае эти датасеты ссылаются на один из датамодулей

В таком случае верхняя форма в иерархии форм, которая работает с БД имеет виртуальный метод

procedure SetDBConnection(AConnection : TSomeDatabaseConnection)

По поводу ненужности централизации обмена с БД (технология фрэймов от vuk)
Редко бывают приложения БД, которые стразу после запуска требуют открытия всех окон и панелек. Все это по необходимости. Т.е. каждая форма (фрэйм) при первой активации должна самостоятельно устаналивать соединение и также содержать в себе весь код по обмену независимо от остальных - я правильно понял ? Например, всяческие поиски, сортировки, статусные строки, сообщения и т.д. фрэйм должен реализовывать самостоятельно ? Грубо говоря, у меня есть 20 форм в проекте, в которых отображаются РАЗНЫЕ объекты БД, но вышеуказанные фичи у них одинаковые. Как  я понял, надо создать один базовый фрэйм, где и реализовать общее, а затем наплодить от него 20 наслелдников, реализующих специфику. Способ, ИМХО, фиговенький и ведет к чрезмерной загруженности проекта модуоями, но ладно, проглотим.
Но вот что интересно - каждый такой фрэйм будет самостоятельно соединяться с базой, открывать датасеты, в т.ч. вспомогательные (например, справочники), УЖЕ ОТКРЫТЫЕ в других фрэймах и т.д. Замечательно просто !
А при открытии нового проекта, если он на 80% схож с написанным, предлагается всю эту кухню с кучей фрэймов тащить в него ? И еще строить из них генеалогические деревья наследования ибо эти 20% тоже как-то надо реализовать :)

 И кто-то берется утвержать, что такая технология лучше датамодульной ?

Но вот что интересно - каждый такой фрэйм будет самостоятельно соединяться с базой

Ты про TDatabase в детстве читал?

vuk ©   (15.01.09 13:09) [44]


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


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

Ega23 ©   (15.01.09 12:59) [43]


> Никто не мешает для таких дел завести отдельный DataModule.
>  Но именно для таких дел, а не помойку из него устраивать.
>


В моих постах есть хоть один намек на предложение устроить помойку ? Если не трудно, ткни пожалуйста в номер поста.

Медвежонок Пятачок ©   (15.01.09 14:10) [46]


> Мой грид имеет волшебный метод :
>
> function BatchProcess(ACallBack : TBlaBlaBlaCallBack; AUserData
> : Pointer; AWholeDataSet : boolean = False) : integer;


У меня в датамодуле могут быть сосредоточены конкретные алгоритмы не имеющие никакого отношения к гридам, формам и контролам. И я хочу эти алгоритмы использовать в невизуальных приложениях.

У меня предок таких датамодулей реализует один или несколько интерфейсов, соответственно, конкретная реализация в наследниках выглядит по-разному, обращение к датамодулям идет через методы интерфейса, ну а наследовать удобно, для того, чтобы часть методов вынести в базовый класс.

>Jeer ©   (15.01.09 13:14) [45]
>тем более, что имеется несколько базовых форм с датасетами и db_компонентами от которых >потом наследуются все прикладные формы.

А вот не стОит, ИМХО, смешивать визуализацию и все с нею связанное (сервисы на клиенте), где, действительно, сам Бог велел использовать наследование и инкапсуляцию, с собственно логикой обмена клиент-сервер, в общем случае совершенно независимой от "экрана".

> MsGuns ©   (15.01.09 15:10) [50]


Ганс, ты не в ту степь полез.
Я что должен открыть туевую хучу датасетов в датамодуле и держать их таковыми для того, что вдруг откроется какая-то визуальная форма, где хрен знает что может потребоваться ? О чем, ты, друг ?

У меня в датамодуле могут быть сосредоточены конкретные алгоритмы не имеющие никакого отношения к гридам, формам и контролам. И я хочу эти алгоритмы использовать в невизуальных приложениях.

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

Если же имелось ввиду использовать алгоритмы везде на произвольных датасетах, подготовленных в других модулях, то у меня такая парадигма:

делаются методы:

1. "Сделай_ЭТО_с_этой_таблицей_в_БД_на_основе_таких-то условий"
2. "Сделай_тоже_самое_с_переданным_датасетом"

дальше посто структурируем процедурно код.
в первой процедуре готовим свой датасет и вызываем второй метод.

Вот пример "из жизни"
Есть достаточно сложный многоступенчатый алгоритм расчета и формирования таблицы применяемости деталей и сборок в изделии, реализуемый на сервере и клиенте в объемном соотношении примерно 20 к 80 (на то есть ряд объективных причин, например то, что данные извлекаются с разных Скл-серверов и нескольких локальных баз).

Этот алгоритм часто-густо используется :

1) Для визуализации конструкторского состава (КСИ) изделия в виде дерева или таблицы, т.е. непосредственно "как есть"

2) Для дальнейшего использования при вторичных выборках, например при составлении план-графика выпуска изделий

3) При выгрузки для печати

Собственно отображать КСИ у пользователя на экране ПК нужно только в первом случае (для этого написано пара-тройка приложений), в остальных случаях, а их десятки, отображать не нужно вообще. Если бы я реализовал КСИ на фрэйме, то пришлось бы каждый раз подключать его к проекту, создавать при запуске вместе с кучей никогда не показываемых визуальных компонентов, заполнять всевозможные пояснительные и прочие котнролы а затем все это килять.
Спрашивается вопрос: а нафига столько лишней работы, пусть даже выполняемой "железкой" ?

Напомню, что КСИ использует несколько соединений, практически полное описание модели данных "классовым" способом вместе с функционалом, тучу специфических типов данных и т.д.
Которые можно было бы реализовать тоже фрэймом, конечно :)))

Воображаю, что из себя в этом случае представляли бы исходники - умереть и повеситься :))

Медвежонок Пятачок ©   (15.01.09 15:20) [55]


> Надо просто экземпляры создавать внутри этих алгороитмов.


Э...не понял мысли


>
> Тогда этот модуль будет действительно универсальным и заюзать
> его можно будет и в гуи и в консоли даже не заглядывая внутрь
> реализации.


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

Не видел нигде статьи с заголовком datamodule inheritance considered harmful

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


Серег, ну чего ты трындишь ?
Визуализирующая форма для чего ? Правильно - для визуализации + возможно для редактирования.
Все.
Отдельные невизуальные механизмы ( уникальные  для какого-либо проекта ) конечно же надо реализововать там, где это удобнее.
Но при чем тут унификация.
Ведь наследование - это прежде всего унификация механизмов + добавочка необходимая.