Как правильно наследоваться от TDataModule?

← →
Игорь Шевченко © (2009-01-15 12:52) [40]

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

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

← →
Медвежонок Пятачок © (2009-01-15 12:55) [41]

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

← →
Игорь Шевченко © (2009-01-15 12:59) [42]

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

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

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

← →
Ega23 © (2009-01-15 12:59) [43]

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

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

← →
vuk © (2009-01-15 13:09) [44]

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

← →
Jeer © (2009-01-15 13:14) [45]

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

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

← →
Медвежонок Пятачок © (2009-01-15 14:10) [46]

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

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

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

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

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

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

← →
Рыбба (2009-01-15 15:04) [47]

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

← →
Jeer © (2009-01-15 15:06) [48]

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

← →
Медвежонок Пятачок © (2009-01-15 15:08) [49]

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

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

procedure SetDBConnection(AConnection : TSomeDatabaseConnection)

← →
MsGuns © (2009-01-15 15:10) [50]

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

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

← →
Медвежонок Пятачок © (2009-01-15 15:16) [51]

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

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

← →
Игорь Шевченко © (2009-01-15 15:17) [52]

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;

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

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

← →
MsGuns © (2009-01-15 15:17) [53]

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

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

← →
Jeer © (2009-01-15 15:19) [54]

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

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

← →
Медвежонок Пятачок © (2009-01-15 15:20) [55]

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

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

← →
Медвежонок Пятачок © (2009-01-15 15:26) [56]

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

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

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

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

← →
MsGuns © (2009-01-15 15:34) [57]

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

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

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

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

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

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

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

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

← →
Игорь Шевченко © (2009-01-15 15:41) [58]

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

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

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

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

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

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

← →
Jeer © (2009-01-15 15:44) [59]

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

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

← →
Медвежонок Пятачок © (2009-01-15 15:45) [60]

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

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

так вот я в таких библиотечных алгоритмах создаю датасеты на рантайме ну или в дизайне лежащие в датамодуле.

или я чего-то не понял в самом вопросе.

в общем у меня нет датасетов двойного и тройного назначения.

← →
Игорь Шевченко © (2009-01-15 15:58) [61]

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

> так вот я в таких библиотечных алгоритмах создаю датасеты
> на рантайме ну или в дизайне лежащие в датамодуле.

Ну вот и я тоже самое делаю

> в общем у меня нет датасетов двойного и тройного назначения.

У меня их тоже нету. У меня нету даже датамодулей двойного назначения. В том-то и смысл, что назначение всегда одно, а вот использование в разных приложениях по мере потребности в том самом назначении - это имеется.
Через датамодули сделано потому, что просто удобнее и писать меньше.
Можно и в ран-тайме все объекты создавать, но не вижу смысла.

← →
MsGuns © (2009-01-15 16:15) [62]

>Jeer © (15.01.09 15:44) [59]
>Серег, ну чего ты трындишь ?
>Визуализирующая форма для чего ? Правильно - для визуализации + возможно для >редактирования.
>Все.

Смотря что считать визуализацией.
Есть такая штука - запасы называется. Они состоят, грубо говоря, из остатка на складе и задела.
И то, и другое, показываются практически одинаково, но расчитываются совершенно по-разному.
Эти самые остатки в одном приложении можно посмотреть в надцати местах: из дерева, из таблицы КСИ, из формы деталоизированной информации по детале(сборки) и еще тучи разных мест формы. Я реализую это с помощью одной разъединственной формочки с сеткой и панелькой динамически "подстриваемой" под нужные контролы отображения деталей. По клику формочка создается, настраивается (заголовок стрингридов, эдиты, чекбоксы, лабельки и т.д, - описания "настроек" в том ДАТАМОДУЛЕ), в ДАТАМОДУЛЕ выполняется нужная выборка и контролы заполняются инфой из списка, заполненного соротв-й функцией ДАТАМОДУЛЯ. Который, выполнив выборку, закрывает НД. Что здесь визуализация ? ДМ не визуализирует сам, но обеспечивает подкачку требуемой инфы ИЗВЕСТНЫМ ТОЛЬКО ЕМУ СПОСОБОМ.
Вот нафига тут вообще наследование ?

>Отдельные невизуальные механизмы ( уникальные для какого-либо проекта ) конечно же надо >реализововать там, где это удобнее.

И я об этом же

>Но при чем тут унификация.
>Ведь наследование - это прежде всего унификация механизмов + добавочка необходимая.

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

← →
Медвежонок Пятачок © (2009-01-15 16:20) [63]

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

← →
vuk © (2009-01-15 16:24) [64]

to MsGuns © (15.01.09 15:10) [50]:
>Т.е. каждая форма (фрэйм) при первой активации должна самостоятельно
>устаналивать соединение и также содержать в себе весь код по обмену
>независимо от остальных - я правильно понял ?

"В действительности всё не так, как на самом деле." (с) не я
Все обстоит совсем не так как описано. По крайней мере у нас.

>Т.е. каждая форма (фрэйм) при первой активации должна самостоятельно устаналивать соединение

Фрейм никогда не устанавливает соединения с БД сам. Это не его дело. Соединениями управляет главный модуль данных. Фрейму соединение с БД либо назначается сверху владельцем либо он может запросить соединение с конкретной БД, но управлять ими он не может. Наборы данных фрейм открывает не при создании, а только тогда, когда ему владелец скажет, что он должен отобразить данные и все параметры, необходимые для работы установлены.

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

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

>Грубо говоря, у меня есть 20 форм в проекте, в которых отображаются
>РАЗНЫЕ объекты БД, но вышеуказанные фичи у них одинаковые.
Не понял. Если объекты разные, то они и отображаются, видимо, по-разному. И функциональность разная. Какие фичи будут одинаковыми?

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

>Но вот что интересно - каждый такой фрэйм будет самостоятельно соединяться с базой,
>открывать датасеты, в т.ч. вспомогательные (например, справочники), УЖЕ ОТКРЫТЫЕ
>в других фрэймах и т.д. Замечательно просто !

Про соединения с базой я уже сказал. Оно одно на все приложение для одной БД (если приложение использует несколько БД, количество открытых соединений будет соответствовать числу используемых в данный момент БД). Вспомогательные наборы данных в 99% случаев зависят от контекста, и поэтому все равно в разных случаях будут разными. На справочники из десятка записей - пофиг, нагрузку на базу создают не они.
Все, что зависит от контекста имеет одну особенность. Если будем вытаскивать всю работу с данными в модели данных, то на каждый фрейм понадобится создавать свой модуль данных, заточенный именно под этот фрейм. Если один фрейм используется в нескольких местах, то контекст во всех случаях, скорее всего, будет разным, использовать один источник данных нельзя и все равно придется подключаться к разным наборам данных. То есть каждый экземпляр фрейма будет работать со своим экземпляром модуля данных. В общем увеличение количества модулей в проекте процентов так на 50. И нафига это всё, если гораздо проще и прозрачнее структура, когда фрейм работающий с данными сам получает эти данные и вся функциональность полностью им реализована и внешние связи сведены к минимуму? Ведь это проще и отлаживать и расширять.

← →
kaif © (2009-01-15 16:29) [65]

Для меня датамолуль это просто контейнер для невизуальных компонентов. Там я обычно держу:

1. ImageList-ы с пиктограммами, если хочу их иметь постоянно под рукой для всяких меню и кнопок.
2. Компонент соединения с базой данных и компонент транзакции по умолчанию на чтение.
3. Компонент TApplication для обработки событий уровня приложения, например, глобальную обработку исключений.
4. Компоненты для мониторинга (например, SQL-запросов)
5. Иногда (очень редко!) некоторые датасеты маленьких часто используемых справочников, например, справочника валют.

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

← →
kaif © (2009-01-15 16:32) [66]

К тому же я пишу двузвенки для IB. А там нет проблем с одновременным стартом множества транзакций в рамках одного приложения. Поэтому и датасеты у меня раскиданы по окнам, а не сконцентрированы в каком-либо глобальном датамодуле. Для приложений баз данных с более критическими ограничениями на транзакции, может быть имеет смысл все помещать в датамодуль. Например, иногда, если я пишу приложения для Access, я все датасеты именно туда и помещаю. Так как в случае с Access так проще.

Единого решения здесь быть не может.

← →
vuk © (2009-01-15 16:32) [67]

to Игорь Шевченко © (15.01.09 15:17) [52]
А догматизм он вообще вреден. Если мне нужно будет отделить логику от отображения, то я отделю. Хоть датамодулем, хоть как. Но я не буду отделять её всегда. У нас большая часть логики живет в MSSQL, а клиент, в основном, только отображением занимается.

vuk © (15.01.09 16:32) [67]

> У нас большая часть логики живет в MSSQL, а клиент, в основном,
> только отображением занимается.

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

> А догматизм он вообще вреден.

Безусловно.

> Если мне нужно будет отделить логику от отображения, то
> я отделю. Хоть датамодулем, хоть как. Но я не буду отделять
> её всегда.

Я скорее не буду смешивать ее с отображением, впрочем, все как всегда зависит от задачи.

>vuk © (15.01.09 16:24) [64]

<последний абзац>

Я так и не понял зачем для каждого фрэйма создавать свой модуль данных ? Я же писал - грид, источник, НАБОР ДАННЫХ - в фрйэм, а алгоритмику выборок (апдейтов), как и всю непрописанную в сетке функциональность датасета (например, события) - в датамодуль.

Зачем в каждом фрэйме (путь даже у предка) иметь СВОЙ код по обработке фактически одного и того же ? Это как раз и есть НЕунификация логики, а совсем наоборот. Т.е. для приведенного выше примера с КСИ мне бы надо было по Вашей технологии создать туеву хучу фрйэмов для каждого вида инфы (пусть даже с минимальным кодом с учетом наследования) не смотря на то, что отличаются они по минимуму ? Вместо этого я создал модель детальной визуализации объектов, положил ее в датамодуль и использую при построении каждой формочки при помощи десятка строк кода. Т.е. у меня один датамодуль (правда немаленький), одна форма с минимумом контролов и кода - и все.
ИМХО, куда проще разобраться с юнитом в 400 строк кода, чем с двумя десятками фрэймов, унаследованных друг от дружки.

Хотя, конечно, каждый поп сам свой устав пишет :)

to Игорь Шевченко © (15.01.09 16:39) [68]
>Я скорее не буду смешивать ее с отображением,
>впрочем, все как всегда зависит от задачи.
А я не вижу причин разделять данные и их отображение, если, как это у нас делается, выборки заточены под конкретное приминение и большее нигде не используются. Если же понадобится какой-то алгоритм реализовать отдельно от всего остального, то средства будут использованы адекватные задаче - где-то вынесение на сервер, где-то датамодули...

to MsGuns © (15.01.09 16:41) [69]
Что такое алгоритмика выборок и апдейтов я в упор не понял. У нас всё живет только через хранимые процедуры и всех алгоритмов при работе с ними - параметры подставить.

vuk © (15.01.09 17:04) [70]

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

У нас обычно используются (где-то еще). Гораздо хуже бывает, когда надо использовать отдельно, а оно уже встроено в компоненты отображения как в салат с озерными грибками. Тогда, разумеется, делается подробная копия алгоритма со всеми его причудами, но без визуальной части. И начинаются страсти с сопровождением.
Нафиг-нафиг.

Ключевые слова здесь - "у нас делается" и "у нас делается".

Тогда, разумеется, делается подробная копия алгоритма со всеми его причудами,

Либо экспресс-рефакторинг для недопущения такого безобразия.

Медвежонок Пятачок © (15.01.09 17:40) [72]

> Либо экспресс-рефакторинг для недопущения такого безобразия.

За это никто не платит. А экспресс-рефакторинг немаленького древнего проекта плюс экспресс-тестирование результатов этого рефакторинга обойдутся в довольно круглую сумму.

нет, не проекта, а куска проекта, для которого потребовался внезапный копи-паст.

Медвежонок Пятачок © (15.01.09 17:53) [74]

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

ну изначально-то все равно не написать так, чтобы потом обо что-то не уколоться.

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

Медвежонок Пятачок © (15.01.09 18:45) [76]

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

Безусловно.

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

"Жаль только, жить в эту пору прекрасную, уж не придется ни мне, ни тебе"
(с)

>vuk © (15.01.09 17:04) [70]
>Что такое алгоритмика выборок и апдейтов я в упор не понял. У нас всё >живет только через хранимые процедуры и всех алгоритмов при работе с >ними - параметры подставить.

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

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

С наилучшими

Если говорить о файловых БД и о запросах, генерируемых на клиенте, то там свои заморочки. Там есть смысл оформлять отдельно алгоритмы генерации запросов. Но это не имеет отношения к датамодулям. Но всё это только для файловых БД. Для клиент-серверных же генерировать запросы в клиенте при наличии хранимых процедур - довольно странное занятие.

Я писал о том, с чем работаю. И ничего никому не собираюсь навязывать.

Как правильно наследоваться от TDataModule? Найти похожие ветки