Ваше мнение на мой подход.

← →
karat © (2004-11-11 09:48) [0]

ВСе чаще приходится создавать приложения для БД. И выработал для себя такой подход. Хотел бы узнать ваше мнение, насколько это вообще правильно.
Для работы с БД я всегда создаю класс. Его методы выполняют обыкновенные стандартные операции типа добавить запись, удалить запись и т.д. (к примеру, TOperation.GetClientCard). Как правило, в конструктор я передаю наборы данных (ADOCommand, ADOQuery), где инициализируются внутренние переменные того же типа. И методы работают уже с ними. Так же есть поля класса, содержащие свойства, специфичные для БД (к примеру ServerName).
Выаше мнение на такой подход?

← →
Nikolay M. © (2004-11-11 10:08) [1]

Видал такой кошмар в одном месте. Не исключаю, что если грамотно построить иерархию классов, оно будет работать красиво и быстро. Но мне пришлось некоторое время провести на поддержке такой программы, где список клиентов выводился не связкой ADODataSet-DataSource-DBGrid, а начитывался в ListView, причем для построения каждой записи делалось несколько запросов к базе! Имхо, автора этого ужаса замучала икота от мата в его адрес...

← →
КаПиБаРа © (2004-11-11 10:23) [2]

karat © (11.11.04 9:48)
И выработал для себя такой подход

Между какими подходами вы выбирали и в чем преимущества именно этого подхода?

← →
Dmitriy O. © (2004-11-11 10:34) [3]

Это извращение

← →
karat © (2004-11-11 10:40) [4]

> Между какими подходами вы выбирали

К примеру, можно просто на обработку каждой кнопки или другого нужного события, вставлять код исполнения SQL запроса, а не метод класса. Или уйти от классов и создать отдельный модуль с процедурами и функциями.

> в чем преимущества именно этого подхода

- С преимуществом столкнулся при разработке MDI приложений. Где есть несколько основных дочерних окон, в которых отображается наиболее важная часть информации для пользователя и допускается возможность открывания сразу нескольких одинаковых окон. Тогда класс, при создании дочернего окна, "привязывается" к нему и работает именно с данными этого окна. При подходе с отдельным модулем функций и процедур (без класса), считаю сложнее осуществивым.
- Читабельность кода модуля форм. В этой ситуации, класс является неким "черным ящиком", от которого интересует только информация на выходе. А что творится внутри него, уже мало интересует (при этом важен проффесиализм программиста). Это как про то, что мы используем функции и процедуры OP, но редко кто(наверное большинство) заклядывает внутрь их.

← →
karat © (2004-11-11 10:42) [5]

> Dmitriy O. © (11.11.04 10:34) [3]
> Это извращение

Что тогда не извращение?

← →
КаПиБаРа © (2004-11-11 11:36) [6]

karat © (11.11.04 10:40) [4]
К примеру, можно просто на обработку каждой кнопки или другого нужного события
Можно все писать в DataModul.

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

Почему бы самому дочерниму окну не работать с данными минуя промежуточные классы? Причем можно создавать несколько дочерних привязаных к одному и тому же набору.

← →
Игорь Шевченко © (2004-11-11 11:53) [7]

> Почему бы самому дочерниму окну не работать с данными минуя
> промежуточные классы?

В примитивных приложениях так и делается (и это именно то, что рекомендует Borland).

← →
by © (2004-11-11 11:56) [8]

Игорь Шевченко © (11.11.04 11:53)
А что рекомендует Borland для не примитивных приложений?

← →
inic © (2004-11-11 12:01) [9]

karat © (11.11.04 9:48)

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

← →
blackman © (2004-11-11 12:02) [10]

>В примитивных приложениях так и делается (и это именно то, что рекомендует Borland).
Это рекомендует Шевченко противный и примитивный Borland :)

← →
Rule © (2004-11-11 12:07) [11]

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

← →
Игорь Шевченко © (2004-11-11 12:08) [12]

blackman © (11.11.04 12:02) [10]

Ты когда-нибудь уймешься ?

← →
msguns © (2004-11-11 12:13) [13]

Есть такой метод (на примере такого же MDI-решения):
1. Создается Датамодуль, в который вшивается то, что глобально для приложения: записи, типы, коннекты, транзакции (для ИБ), методы, применяемые большинством объектов (например, обработчики событий датасетов) и т.д.
2. Создается по одной базовой форме на каждый тип интерфейсного окна (окно справочников, окно документов, окно редактирования записей и т.д.), где максимально прописывается реализация (обработчики акций, поп-ап меню, связка с коннектом, транзакциями и т.д.)
3. Из базовых форм достаточно быстро мастерятся интерфейсные (пользовательские) формы, которые "наточены" на конкретные объекты БД или предмета (таблицы, отчеты). Большинство функций уже определены (отображение текущего состояния датасета, обработчики вставки-удаления-изменения, перечитка с позиционированием, всевозможные поиски-фильтры-сортировки и т.д.) в форме-папаньке, остается только "заточить".
4. Формы в ране создаются динамически и после закрытия уничтожаются. Наряду с минусами (многажды открытая одна и та же форма, что приводит к лишним транзакциям или загрузке кэша одной, потеря узером "фокуса" и т.д.) есть и плюсы (можно одну и ту же таблицу отсортировать неск.способами и сравнить результаты в неск.окнах)
5. Никаких коррекций в гридах ! Только через формочки, не связанные напрямую с данными. Все модификации через автономные запросы (TIBSQL). Все, что должно заключаться в одну логически целостную операцию (например, проводка документа), через ХП в отдельной транзакции.

Уф, увлекся ;)))

← →
Игорь Шевченко © (2004-11-11 12:18) [14]

msguns © (11.11.04 12:13) [13]

Как все до боли знакомо :) Я уже давно иду в сторону от подобного подхода, вынося функциональность бизнес-логики в отдельные классы или, в ряде случаев, в те же DataModule, так, чтобы форма преимущественно не знала об конкретном источнике данных для отображения.

← →
КаПиБаРа © (2004-11-11 12:22) [15]

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

← →
msguns © (2004-11-11 12:28) [16]

>Игорь Шевченко © (11.11.04 12:18) [14]

.. и напрашивающийся шаг: вынести классы в саму базу и написать средство их юзанья и апдэйта извне..
И получим образчик Объектной модели БД. Но это уже совсем другая песнь.

← →
Rem © (2004-11-11 13:33) [17]

У меня сделано так:
1. Есть службы бизнеса (хотя, они интегрируют в себе частично службы данных) - компоненты для работы с конкретными сущностями БД. Они реализуют методы для открытия списков, редактирования элементов. Эти методы вызывают обработчики, привязанные к соответствующим событиям (OnExecuteList, OnOpenDocument, OnEditDocument, OnDeleteDocument, OnRestoreDocument). В этих обработчиках пользователь может подключать свои (внешние для набора компонентов) формы (например, форму для отображения списка клиентов или форму редактирования данных о клиенте) или выполнять любые другие действия. Кроме этого, служба бизнеса содержит закешированный список - грубо говоря, открытую таблицу БД (хотя, это чаще всего именно запрос к нескольким таблицам БД) - то-есть то, что пользователь должен видеть в списке (например, Фамилию, Имя, Отчество, Адрес клиента (из таблицы "Клиенты"), Электронную подпись автора записи (из таблицы "Пользователи") и пр). Для чего это нужно: Вновь открываемые представления списка (а они могут отличаться за счет установки фильтров) не должны делать запроса к БД, так как данные уже на клиентской машине, и их нужно только клонировать. Для того, чтобы обеспечить актуальность кешированных данных, центральная служба данных (она общая для всех бизнес-служб) занимается синхронизацией данных. В результате траффик практически на нуле, так как пользователи загружают список при запуске приложения, а после этого происходит только синхронизация единичных записей.

2. Есть набор компонентов для работы со списками - от простого клона в памяти - до табличного представления. Они подключаются к службам бизнеса. Эти списки открываются не путем запроса из БД, а путем простого клонировани НД. В результате - экономия памяти и синхронизация данных. То-есть, поьзователь может открыть множество списков (журналов), например, приходных накладных за разные диапазоны дат (с любым пересечением), а набор данных у этих списков будет один и тот же. Причем, в случае изменения записей одним ихз пользователей в сети, эти данные автоматически ихзменяются во всех списках у всех пользователей. Траффик в момент синхронизации - на уровне 0.1 - 0.2% от общей пропускной способности сети (локальная сеть 100 мбит, 8 одновременно работающих пользователей) по данным Диспетчера задач Windows XP.

3. Есть набор компонентов (расширения DataSet"а) с методами управления документами (создать новый, открыть, записать), которые подключаются к службам бизнеса. Службы бизнеса запрашивают данные напрямую из БД и передают их в DataSet"ы. При записи службы бизнеса контролируют корректность записываемых даных и пишут напрямую в БД. После этого инициируют синхронизацию данных в кеше списков (для всех пользователей, подключенных к БД).

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

Уффффффф....
:)

← →
Rule © (2004-11-11 14:07) [18]

ух ну вы тут навкладывали :)

← →
Гавирла (2004-11-11 14:12) [19]

> [1] Nikolay M. ©

тоак проблема наверно не в том, что через классы в LIstView
а в том, что несколько запросов на одну запись ?

← →
blackman © (2004-11-11 14:22) [20]

>Игорь Шевченко © (11.11.04 12:08) [12]
Ничего уж и сказать нельзя :)
Учебник: Создание приложений для работы с базами данных
http://articles.org.ru/lection/sozdbd.php
Не надо мудрствовать :)

← →
DiamondShark © (2004-11-11 14:27) [21]

> blackman © (11.11.04 14:22) [20]

То, что там описано, и есть примитивное приложение.

← →
Суслик © (2004-11-11 14:30) [22]

Советую почитать книгу
Мартин Фаулер
Архитектура корпоративных программных приложений.
Она есть на www.books.ru

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

Там и такой подход есть. Это либо паттерн аctive row, row data gateway, table data gateway, table module (точно понять по приведенной инфе невозможно).

← →
Rule © (2004-11-11 14:36) [23]

blackman © (11.11.04 14:22) [20]

БРРРРРРРРРРРРРРРРРРР, это БДЕ, вы что ... не нада даже напоминать о нем.
С тех пор как с него ушел, я стал намного счастливее :)

← →
by © (2004-11-11 14:40) [24]

Суслик © (11.11.04 14:30)
Читал я Фаулера. Он много расписывает подход для модели предметной области, все через классы, когда представление (форма) ничего не должна знать о том где класс берет данные, все в коллекциях. И очень мало он пишет о подходе для модуля таблицы, когда все основано на датасет. При это говорит, что для С# модуль таблицы может подходить больше, но равноценного с моделью предметной области примера и применения не приводит.
Много говорится что модель предметной области лучше, гибче, но чем конкретно она лучше не понятно. Особенно не понятно это для языков, которые имеют родные средства работы с модулем таблицы, для Delphi, для C#.
Может кто объяснит, в чем превосходство?

← →
DiamondShark © (2004-11-11 14:41) [25]

Это верно. БзДЕ должно сдохнуть.
Обидно только, что другие технологии доступа, реализованные в Дельфи фактически копируют ублюдочную идеологию бзде.

← →
Суслик © (2004-11-11 14:43) [26]

> [24] by © (11.11.04 14:40)

> Много говорится что модель предметной области лучше

> Может кто объяснит, в чем превосходство?

Не знаю :))) Вернее мнение есть, но это не для форума - долго очень.

Я уже, как выяснилось живу с моделью предметной области не первый год, пока мне нравится.

← →
by © (2004-11-11 14:49) [27]

[26] Суслик © (11.11.04 14:43)
Жаль что мнение не для форума, очень хотелось услышать.
Я начинал в свое время, в первом проекте, как теперь понимаю с модели предметной области. Очень много текста приходилось писать.
Потом перешел на модель таблицы данных, с DBAware компонентами.
Теперь иду по пути отделения логики от предаставления, но без коллекций, а используя как основу класса датасет, и не отказываясь от гридов.

Вот здесь есть open-source проект, который использует только модель предметной области, все согластно паттернам проектирования. Как серьёзный пример, очень показательно.
TechInsite Object Persistence Framework
http://www.techinsite.com.au/tiOPF/ReleaseBuild

Вот бы такое увидеть и для модели таблицы.

← →
Игорь Шевченко © (2004-11-11 14:49) [28]

DiamondShark © (11.11.04 14:41) [25]

А эта...если не секрет, в чем беда идеологии BDE ?

> [27] by © (11.11.04 14:49)

> Очень много текста приходилось писать.

Я не вижу в этом проблемы. Код, если он написан хорошо и един (а не разнесен по разным местам: pas и dfm) поддерживатся точно также как меньший код, но разнесенный.

[29] Суслик © (11.11.04 14:51)
Насчет того что легче поддерживать код в pas это да. Я и начичинаю потому отделять форму от логики, так как запарился в дизайн тайме искать где изменилась длина поля и пр.

> Насчет того что легче поддерживать код в pas это да. Я и
> начичинаю потому отделять форму от логики, так как запарился
> в дизайн тайме искать где изменилась длина поля и пр.

Скажу больше, что я давно (еще года 3 назад) запарился вообще компоненты кидать. Кидаешь быстро, медленно правишь (все бывает, иногда и это нужно). Код + заточенная на мои проблемы оболочка (в основном, в виде внешних методов) над vcl мне нравятся больше.

Конечно, это все мое личное мнение.

Игорь Шевченко © (11.11.04 14:58)
Да вот и меня масштаб этого framework слегка озадачил. Да и не готов я отказаться от грида как представления набора данных. Может еще и по потому что мне приходится писать приложения, которые оперируют буольшими наборами данных (биллинг), и загонять это в коллекции как то не хочется. Хотя может я и не прав. Уже пол года на распутье, как писать следующий проект.

> [34] by © (11.11.04 15:02)

Биллинг?
Это особая статья. Это систему вряд ли можно отнести к тем системам, про которые говорит Фаулер.

Думаю, что для биллинга такой подход вряд ли подойдет.

by © (11.11.04 15:02) [34]

> Да и не готов я отказаться от грида как представления набора
> данных

Так вот и я не готов. Ни от грида, ни от прочих Data-aware controls, так как во-первых, удобно, во-вторых - уже написано, отлажено и, главное, протестировано многими пользователями.
Я вот до сих пор не могу себе ясно представить, как можно opf совместить с привычной идеологией разработки приложений в Delphi, так, чтобы при этом еще и не писать код в объеме, подобном tiopf.

>DiamondShark © (11.11.04 14:41) [25]
>Обидно только, что другие технологии доступа, реализованные в Дельфи фактически копируют ублюдочную идеологию бзде.

Нельзя ли для особо бестолковых прокомментировать:
1. Какие технологии копируют ?
2. Что именно копируют ?
3. В чем "ублюдочность" биде ?

> Игорь Шевченко © (11.11.04 14:49) [28]
> DiamondShark © (11.11.04 14:41) [25]
>
> А эта...если не секрет, в чем беда идеологии BDE ?

А в ней от десктопных и файл-серверных БД рудиментов много.

Впрочем, я попутал. Не в самой БзДЕ, конечно, а в БД-компонентах.

Если бы существовало однозначное решени для всех авриантов, оно бы уже было бы реализовано, а так имеет то что имеем :)

Ваше мнение на мой подход. Найти похожие ветки