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

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

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

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

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

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


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


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


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


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

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

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

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

 И я об этом же

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]
>Что такое алгоритмика выборок и апдейтов я в упор не понял. У нас всё >живет только через хранимые процедуры и всех алгоритмов при работе с >ними - параметры подставить.

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

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

С наилучшими

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

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