Реализация БД-приложений

← →
GRAND25 © (2004-09-06 17:02) [0]

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

Итак, суть самой задачи. Имеется документ, являющий собой приходный ордер на склад. Документ может содержать в себе неограниченное количество единиц складского учета, относящихся к нему. Задача: обеспечить ввод и редактирование приходных ордеров и объектов складского учета. Просто? Вроде бы да.

1 подход. В БД создается таблица приходных ордеров и таблица объектов учета. Во второй таблице есть поле, являющееся внешним ключом на первую. Классическая связь один-ко-многим. В клиентском приложении есть два датасета, связанные между собой соотношением Master-Detail. Форма клиентского приложения, которая будет обеспечивать ввод/просмотр/редактирование записей, состоит из элементов управления, привязанных (bounded) к конкретным полям базы данных. Грид внизу формы позволяет выбрать нужную запись для редактирования. Пользователь работает с базой данных напрямую, имея возможность ввести новую запись или отредактировать уже имеющуюся.

2 подход. В клиентском приложении разрабатываются классы, являющие собой приходный ордер и объект учета. Класс приходного ордера содержит в себе коллекцию (collection) из объектов учета, относящихся к нему. Форма клиентского приложения, которая будет обеспечивать ввод/просмотр/редактирование записей, состоит из элементов управления, не привязанных (unbounded) к конкретным полям базы данных. Грид внизу формы показывает уже введенные объекты учета. В процессе ввода клиентское приложение в памяти локальной рабочей станции формирует и хранит приходный ордер с коллекцией его объектов учета. В разработанных классах имеются методы InsertToDB, которые физически добавляют новую запись в соответствующую таблицу. По нажатию кнопки "Сохранить" происходит запись введенных объектов из памяти в базу данных (сначала приходный ордер, а потом циклически по всей коллекции все объекты складского учета).

Какой из этих подходов вы считаете наиболее рациональным, современным и правильным? А может быть вы просто симпатизируете какому-то из них "потому что"? Прошу высказываться. Если нетрудно, аргументируйте свой ответ, опишите, какие стороны того или иного подхода вы считаете сильными, а какие слабыми.

Заранее благодарен.

← →
Ega23 © (2004-09-06 17:10) [1]

Что-то я второй способ не до конца понял. Это что, у тебя всего один клиент?

По вопросу: в первом продходе предлагаешь редактирование напрямую в гриде?

← →
GRAND25 © (2004-09-06 17:14) [2]

> Что-то я второй способ не до конца понял. Это что, у тебя
> всего один клиент?

В каком смысле один? Клиентское приложение одно, работающих экземпляров несколько.

> По вопросу: в первом продходе предлагаешь редактирование
> напрямую в гриде?

Да, грид связан со своим источником данных. Редактирование в гриде автоматически означает редактирование в таблице БД (разумеется, после вызова метода Post).

← →
Игорь Шевченко © (2004-09-06 17:15) [3]

> Какой из этих подходов вы считаете наиболее рациональным,
> современным и правильным?

Второй.

← →
Sergey_Masloff (2004-09-06 17:17) [4]

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

← →
Ega23 © (2004-09-06 17:19) [5]

Вообще-то ни тот, ни другой... :о)
В смысле, не считаю правильным или неправильным, а просто симпатизирую к третьему.... :о)

← →
Sergey_Masloff (2004-09-06 17:20) [6]

Блин, тема интересная. Давно хотел по этому поводу с народом пообщаться - но только с теми кто шишек уже понабивал.

← →
GRAND25 © (2004-09-06 17:23) [7]

2 Игорь Шевченко: обосновать есть чем?

← →
Sergey_Masloff (2004-09-06 17:26) [8]

Кроме того второй подход сложнее при работе с коллекциями - например в счете фигурируют документы каждый из которых свой сложный объект. Манипулируя датасетом а не объектом коллекции очень просто (потому что все написано давно) мгновенно менять состав полей - ну допустим кроме номера документа я захотел видеть еще пару других реквизитов - переписывай коллекцию ;-) А не одну строчку SQL.
Проблемы с LazyLoad когда один объект может возникать как дочерний ко многим - приходится реализовать счетчик ссылок или его аналог что реализуемо но трудоемко читай потенциально глючно. И др.
Но все же окончательно эту идею я не похоронил, просто продумываю "новый виток". А так пока шишек больше чем плодов (хотя проект успешный вполне - но традиционными технологиями я б его быстрей сделал).

← →
by © (2004-09-06 17:29) [9]

Как написано у Фаулера, в его Архитектуре корпоративных приложений, есть три метода реализации корпоративных приложений (за дословность не ручаюсь, книга дома, может кто подправит)
1) процедурный, все делаем через процедуры/функции на клиенте или структурный
2) все представляем через классы
3) все представляем через работу с набором данных.
Он говорит что наиболее прогресивен метод определения предметной области через классы и их взаимодействие. Но для языков программирования которые поддерживают концепцию dataset/recordset (Delphi, C#) и емеют средства для работы с ней (grid, dbaware edits) очень подходит и модель работы с набором данных

← →
by © (2004-09-06 17:35) [10]

Но при работе только через объекты очень много нужно писать. Кода больше чем при работе с датасетом. Мой первый проект в котором я участвовал был полностью построен на идеологии объектов, без DBEdit-ов, и писалось кода довольно много. При дальнейшей работе, когда в других проектах я сам стал писать базовые класы я перешел к идеологии датасета, так как таким образом можно было писать с меньшими затратами и использовать то что уже реализовано в среде разработки. Счас, после прочтения книг, опять на распутье.

← →
Игорь Шевченко © (2004-09-06 17:38) [11]

GRAND25 © (06.09.04 17:23) [7]

> 2 Игорь Шевченко: обосновать есть чем?

Фаулер. Архитектура корпоративных приложений.
Фаулер. Рефакторинг. Раздел "Дублировние видимого кода".

Sergey_Masloff (06.09.04 17:17) [4]

> п. 2 требует на порядок больших усилий как на разработку
> так и на поддержку. Хотя в теории более "красив".

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

← →
Iconka © (2004-09-06 17:42) [12]

> Фаулер. Архитектура корпоративных приложений.
> Фаулер. Рефакторинг. Раздел "Дублировние видимого кода".

В электронном виде есть?

← →
GRAND25 © (2004-09-06 17:46) [13]

Неясно, что обеспечит гибкость проекта при втором подходе?

> я захотел видеть еще пару других реквизитов - переписывай
> коллекцию ;-) А не одну строчку SQL.

Вот золотые слова! Бизнес-логика где будет? Правильно, на клиенте. Тогда неясно, зачем и кому нужна будет вся мощь SQL-сервера с его триггерами и SP? И потом, полагаться не на аппаратное обеспечение одного сервера, а множества воркстейшенов?

← →
by © (2004-09-06 17:47) [14]

В электронном виде есть?

я не нашел, пришлось покупать
правда Refactoring на английском нашел

← →
GRAND25 © (2004-09-06 17:50) [15]

Игорь, Фаулер - это все хорошо, свое мнение на данный счет у тебя на чем базируется? Опытом поделиться можешь, как ты разрабатывал приложения, пользуясь подходом №2, и какой неизгладимый след в твоей душе этот подход оставил?

← →
Sergey_Masloff (2004-09-06 17:51) [16]

Sergey_Masloff (06.09.04 17:17) [4]

>Да и на практике тоже неплох, по крайней мере, своей гибкостью, >в ряде случаев.
Да я и не спорю. Но очень много писать... и очень одинакового. Примеры Фаулера пока не очень убеждают - все же он видимо больше знаком с Java где все не совсем так. Тем более он явно указывает что в ряде случаев NET датасет вполне применимое решение.

И с гридами. Все же грид + навигатор настолько удобная и привычная пользователям вещь... Соответственно на ее эмуляцию в случае объектов тоже время (а время - деньги). Или объект - коллекция как обертка над датасетом - тоже что-то не очень нравится.

Есть еще много сложных и спорных моментов. Вобщем, то ли руки мне еще править и править но пока полного консенсуса с чисто объектным подходом не получилось у меня.

← →
by © (2004-09-06 17:51) [17]

Ну использовать stored proc можно и при использовании объектов, но тот же Файлер против этого, растаскивание бизнес логики по нескольким местам, да и не все реализуемо через язык SP

← →
Игорь Шевченко © (2004-09-06 17:53) [18]

GRAND25 © (06.09.04 17:50) [15]

> свое мнение на данный счет у тебя на чем базируется?

На опыте и прочтении того же Фаулера.

> Опытом поделиться можешь, как ты разрабатывал приложения,
> пользуясь подходом №2, и какой неизгладимый след в твоей
> душе этот подход оставил?

А ты почитай Фаулера, он довольно подробно все излагает...

← →
Игорь Шевченко © (2004-09-06 17:54) [19]

Sergey_Masloff (06.09.04 17:51) [16]

> Или объект - коллекция как обертка над датасетом - тоже
> что-то не очень нравится.

А чем не нравится ?

← →
Sergey_Masloff (2004-09-06 17:57) [20]

by © (06.09.04 17:51) [17]
>Ну использовать stored proc можно и при использовании объектов, >но тот же Файлер против этого, растаскивание бизнес логики по >нескольким местам, да и не все реализуемо через язык SP
Ну вот тут он однозначно не прав. На языке SP можно реализовать практически все. И зачастую гораздо проще чем на клиенте - потому что в КОРПОРАТИВНЫХ системах очень часты случаи когда для определенных действий требуются множество данных из базы за которыми лезть из клиента очень накладно и код хранимой процедуры на PL-SQL в 20 строчек превращается в 400 строк клиентского кода с десятком обращений к серверу.

← →
GRAND25 © (2004-09-06 18:00) [21]

> На опыте и прочтении того же Фаулера.

> А ты почитай Фаулера, он довольно подробно все излагает...

Веско, спасибо!

← →
by © (2004-09-06 18:01) [22]

Для себя я пока избрал подход слияния объекта и датасета. Например, у меня есть базовый класс TBaseForm, от него наследник TListForm, который и содержит грид, кнопки и пр. Его наследники, например TListGoods (справочник товаров) и есть объекты моей системы, у них есть методы типа Refresh, makeSQL, DeleteRec и пр. Это объектная часть. А часть датасета - это то, метод makeSQL или DeleteRec работает уже непоследственно и датасетом и применяет DBAware компоненты.

← →
by © (2004-09-06 18:04) [23]

Sergey_Masloff (06.09.04 17:57) PL-SQL в 20 строчек превращается в 400 строк клиентского кода с десятком обращений к серверу

это да, но как быть в случаях когда нужно работать с несколькими источниками данных, когда основная БД на Firebird, а данные в неё заливаются из dbf, текстовых файлов, и в этой заливке много бизнес логики. Тут одними SP не обойдешься

← →
}|{yk © (2004-09-06 18:07) [24]

Кстати, об этом я написал статью, скоро появится на delphimaster.ru

← →
Sergey_Masloff (2004-09-06 18:10) [25]

by © (06.09.04 18:01) [22]
То что ты описываешь это то как у меня текущий проект. Его я объектным не называю и вот по какой причине - у меня была мечта (как у М.Л. Кинга) все же отделить объекты от их визуального представления. Чтобы объект ничего не знал о формах которые его отображают (да и форм бы не было допустим).
Кроме теоретической пользы я преследовал практическую цель - мне нужно было дать вовне мой объект внешнему приложению которое использовало бы его для работы с нашей базой. Мне это удалось вобщем-то но затраты времени на реализацию оказались очень большими. Правда одной из причин было то что многие операции с данными делались в базе, то есть был маппинг базы на объекты двойной - при определенных действиях состояние объекта в БАЗЕ менялось приходилось маппить все это на объект а потом и на внешнее представление.

← →
GRAND25 © (2004-09-06 18:13) [26]

Кроме того, возможны ситуации, когда корректность введенных пользователем данных нужно проверить на основании данных из множества других таблиц. В этом случае триггер на сервере рулит. А объект какого-либо класса - слишком изолированная вещь. Его связи с другими объектами придется поддерживать множественными обращениями к БД и подгрузками данных оттуда. В результате даже какая-нибудь самая элементарная проверка корректности может вылиться в нешуточные тормоза.

← →
Sergey_Masloff (2004-09-06 18:14) [27]

Игорь Шевченко © (06.09.04 17:54) [19]
>> Или объект - коллекция как обертка над датасетом - тоже
>> что-то не очень нравится.

>А чем не нравится ?

Ну а тогда чем форма не объект? На нее датасеты датаконтролы и датасорсы - вот и получили объектный подход ;-)

Ну это я утрирую. Я думал о клиент датасете как о элементе реализации объектов коллекций. Пока без практических выводов. К сожалению катастрофически не хватает времени - текучка душит :(((

← →
by © (2004-09-06 18:18) [28]

Sergey_Masloff (06.09.04 18:10)

мечта такая у меня есть и сейчас, заманчиво реализовать Model View Controler и прочее. Но из реалий я вижу что очень много нужно писать, намного больше чем при модели через датасет, и это сдерживает.

← →
GRAND25 © (2004-09-06 18:19) [29]

Далее. Интересно было бы рассмотреть, какое приложение производительнее: то, которое по ходу своей работы вставляет записи в таблицу БД физически или то, которое хранит все в памяти, а потом оптом сливает в базу записей эдак 70?

← →
Sergey_Masloff (2004-09-06 18:22) [30]

GRAND25 © (06.09.04 18:19) [29]
>Далее. Интересно было бы рассмотреть, какое приложение >производительнее: то, которое по ходу своей работы вставляет >записи в таблицу БД физически или то, которое хранит все в >памяти, а потом оптом сливает в базу записей эдак 70?
70 записей? Без разницы если конечно не на диалапе это все происходит. Единственно что может быть выгоднее - длина вставляющей транзакции. Но это не всегда критично.

← →
Игорь Шевченко © (2004-09-06 18:23) [31]

Sergey_Masloff (06.09.04 18:14) [27]

Я почему спросил, чем не нравится, потому что мы испытывали сомнения при подобном же подходе. И от грида в ряде случаев не хочется отказываться и честь соблюсть. Кстати, в приснопамятной программе МАРС такой подход использовался, с ClientDataSet для работы с гридом, я бы не сказал, что это сильно усложнило работу.

← →
Sergey_Masloff (2004-09-06 18:34) [32]

Игорь Шевченко © (06.09.04 18:23) [31]

>Кстати, в приснопамятной программе МАРС такой подход >использовался, с ClientDataSet для работы с гридом, я бы не >сказал, что это сильно усложнило работу.
Да вроде бы не сильно. Правда я не помню как там с такой ситуацией:
- в базе коллекция объектов
- она отобразилась на коллекцию
- коллекция на датасет
- в датасете пользователь удалил запись потом вставил другую
когда идет обмен с базой?
если в момент обратного отображения клиентдатасета на коллекцию то нужно еще смотреть историю удалений, если параллельно с удалением из датасета - то часто дергается соединение с базой что не совсем то чего хочется достичь.

← →
Игорь Шевченко © (2004-09-06 18:37) [33]

Sergey_Masloff (06.09.04 18:34) [32]

> - в базе коллекция объектов
> - она отобразилась на коллекцию
> - коллекция на датасет
> - в датасете пользователь удалил запись потом вставил другую
> когда идет обмен с базой?

В момент сохранения всего объекта со всеми коллекциями в базе данных.

← →
TohaNik © (2004-09-06 18:40) [34]

>Sergey_Masloff (06.09.04 17:51) [16]

Вобщем, то ли руки мне еще править и править но пока полного консенсуса с чисто объектным подходом не получилось у меня.

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

это да, но как быть в случаях когда нужно работать с несколькими источниками данных, когда основная БД на Firebird, а данные в неё заливаются из dbf, текстовых файлов, и в этой заливке много бизнес логики. Тут одними SP не обойдешься

ИМХО здесь другое - подготовка данных чтобы были съедобны Firebird

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

← →
Sergey_Masloff (2004-09-06 18:55) [35]

Игорь Шевченко © (06.09.04 18:37) [33]

У меня возникали проблемы когда объект может быть элементом нескольких коллекций одновременно. Когда возникают (в силу предметной области или кривых рук) отношения объектов не как деревьев а как графов.
Ну (из теперешней области)
Есть полис (объект).
В нем есть коллекция участников и их ролей
Полис - Роль (объект) <- Субъект (физ или юр. - объект)
\ Роль (объект) <- Субъект (физ или юр. - объект)
...............................................

Кроме этого есть коллекция застрахованных объектов
Полис - Объект <- Это тоже может быть субъект
\ Объект <- а у этого объекта есть владелец - и он тоже субъект.

Вобщем идея понятна - один и тот же объект (допустим физ. лицо) входит в несколько коллекций и из нескольких коллекций может быть к нему обращение с целью модификации. То есть возникает дилемма - хранить несколько таких объектов - проблеме синхронизации так как в разных могут оказаться разные данные. И запишется в базу - только один из вариантов (который будет сохраняться последним). Вариант второй - то что у Фауоера называется LazyLoad с пулом объектов. Я это и сам придумал до (ну ладно не до а независимо) от Фаулера только так красиво не смог название придумать. Но реализация не такая простая всего этого дела :(

← →
GRAND25 © (2004-09-06 19:01) [36]

Короче, пошлите подальше всю мощь, предоставляемую современными серверами реляционных БД, вооружайтесь ООП, продумывайте механизмы взаимодействия данных сами, оптимальное взаимодействие объектов с физической БД тоже продумывайте сами, вобщем, напишите свой собственный движок и наслаждайтесь жизнью!

"... до основанья. А зачем?"

← →
iZEN © (2004-09-06 19:12) [37]

2-й подход более объектно-ориентирован и более соответствует предметной области (моделирует реальные отношения).
Без сомнения он правильнее первого подхода, но он труден в реализации.

← →
iZEN © (2004-09-06 19:24) [38]

/**by © (06.09.04 18:18) [28]
мечта такая у меня есть и сейчас, заманчиво реализовать Model View Controler и прочее. Но из реалий я вижу что очень много нужно писать, намного больше чем при модели через датасет, и это сдерживает.
*/
Совсем немного. Просто нужно взять/понять суть паттерна MVC и стараться не использовать "левого" толка.

Кстати, для работы с БД по парадигме MVC необходимо придумать политику обновления Вида, так как Модель, Вид и Контроллёр будут находиться на разных компьютерах и соединяться по относительно медленным каналам. Такая политика есть и описывается специальным(и) паттерном(ами) проектирования.

← →
TohaNik © (2004-09-06 20:02) [39]

iZEN © (06.09.04 19:24) [38]

Ну а разве разработка модели это совсем немного...?

Наверное всетаки спор из-за того что предполагается исп-е ASP.NET
где где идеология "несколько" другая.

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

← →
GRAND25 © (2004-09-06 20:11) [40]

Вопрос: на хрена все эти суперпрофнавыки? Вообще, зачем воротить такую телегу в памяти рабочей станции, на которую, как правило, умные люди всегда возлагают настолько мало ответственности, насколько это возможно? Временно похранить в памяти данные в супернавороченной объектной структуре некоторое время, чтобы потом вылить это все в БД? Смысл? Выигрыш? Где?

← →
Petr V. Abramov © (2004-09-06 20:36) [41]

Второй способ сводится к dataset`ам c CachedUpdates. А если еще не полениться написать с десяток базовых форм, все разновидности ордеров/накладных клепаются без единой строчки кода.

/**GRAND25 © (06.09.04 20:11) [40]
Временно похранить в памяти данные в супернавороченной объектной структуре некоторое время, чтобы потом вылить это все в БД? Смысл? Выигрыш? Где?
*/
А если отойти от концепции один_сервер-много_клиентов и посмотреть на конфигурацию, в которой нет сервера, вообще. Только клиенты и у каждого свои данные, с которыми они работают и обменивается с другими, если приспичит.
Распределённая БД.
Накой х. одному клиенту хранить данные или иметь доступ к ним, не относящиеся к его специфике работы? Или: нужно получить данные с соседнего компа, расположенного в 5-и метрах от него, а не лезть на сервер в другом городе и спрашивать разрешения...

Унифицированная объектная реализация модели такой распределённой БД в P2P-обменах существенно экономит силы и время на сопровождение и поддержку, снижает риски из-за отказов оборудования в тысячи раз.

/**Petr V. Abramov © (06.09.04 20:36) [41]
А если еще не полениться написать с десяток базовых форм, все разновидности ордеров/накладных клепаются без единой строчки кода.
*/
Признайтесь, под "десяток базовых форм" Вы хотели сказать: "Виды" (из MVC)?
Ну, тогда уж не "базовые", а что ни на есть КОНКРЕТНЫЕ. (А то код получится слишком большой).

to iZEN © (06.09.04 20:57) [42]:
>Только клиенты и у каждого свои данные, с которыми они работают
>и обменивается с другими, если приспичит.
Угу, а целостность и непротиворечивость Пушкин будет обеспечивать.

>Унифицированная объектная реализация модели такой
>распределённой БД в P2P-обменах существенно экономит силы и
>время на сопровождение и поддержку, снижает риски из-за отказов
>оборудования в тысячи раз.
Ну и? Еще где-нибудь сие применяется?

> Унифицированная объектная реализация модели такой распределённой БД <skip>
Много геморроя для поддержания целостности при многопользовательской работе при конкуренции по записи.

/**TohaNik © (06.09.04 20:02) [39]
iZEN © (06.09.04 19:24) [38]
Ну а разве разработка модели это совсем немного...?
Наверное всетаки спор из-за того что предполагается исп-е ASP.NET
где где идеология "несколько" другая.
*/
В том-то и дело, что главное здесь: ПРАВИЛЬНО понять и описать МОДЕЛЬ, а имплементация MVC - дело второстепенное (то есть уже известное, только напильником доработать нужно).

Выразить Модель в виде COM+/EJB/JDO/etc. с маппингом на БД - вот в чём сложность. Но на то и существуют проектировщики и программисты.

to vuk © (06.09.04 21:03) [44].
Я же сказал: сервера нет и не было. О непротиворечивости данных заботится пользователь и его ПО синхронизации.
Это была гипотетическая ситуация, а в главной теме автор кажется хочет отталкиваться от классической схемы сервер_БД-клиент.

/**vuk © (06.09.04 21:03) [44]
Ну и? Еще где-нибудь сие применяется?
*/
Napster, Kazaa, Gnutella, etc. - обмен информацией на основе P2P.

to iZEN © (06.09.04 21:14) [48]:
>обмен информацией на основе P2P
Применяется ли это еще где-нибудь, кроме P2P? Имелось в виду именно это.

> О непротиворечивости данных заботится пользователь и его ПО синхронизации.
Вы представляете себе это "ПО синхронизации" и сколько нехилых по сложности задач оно должно решать? Поставьте Oracle Real Application Cluster, почитайте документацию, и Вам расхочется нагружать этим пользовательскую машину. Да, Oracle - монстр, но именно из-за того, что решает объективно сложные задачи

Sergey_Masloff (06.09.04 18:55) [35]

Да, в этом случае, наверное, имеет смысл завести кэш нужных объектов, которые могут модифицироваться из разных мест. Именно то, что называется LazyLoad, у меня такие коллекции имеют в имени суффикс Cache, так как реализовывал я их до чтения Фаулера.
Насчет простоты реализации - все зависит от того, в какой момент изменения должны быть видимы другим участникам (другим приложениям, например), тогда можно записывать либо каждое изменение (write through) либо самое последнее (Lazy Write). Методов реализации кэша данных тоже есть и разных.

GRAND25 © (06.09.04 20:11) [40]

> Вопрос: на хрена все эти суперпрофнавыки?

Чтобы решать задачи.

> Вообще, зачем воротить такую телегу в памяти рабочей станции,
> на которую, как правило, умные люди всегда возлагают настолько
> мало ответственности, насколько это возможно?

Умные люди строят разные модели программного обеспечения, в том числе и многозвенные.

> Смысл? Выигрыш? Где?

А Фаулера-таки надо читать. Он дядька умный.

В основном ориентируюсь на следующие пункты...

1) если использую db-компоненты, то все они в RO
2) для просмотра набора данных использую дбгриды, одиночные записи вывожу в нужном виде при помощи обычных не db компонентов...
3) для добавления записей, использую форму ввода на базе не db-компонентов, на которой кнопка OK становится активной, только если все введённые значения удовлетворяют заданным условиям.
4) данные одиночной записи храню либо в виде локальных переменных, либо record"a, в зависимости от количества полей, сложности данных и наличия вспомогательной информации.

Сильно не пинайте... это мои наработки, на базе небольшого опыта работы с БД :)

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

/**vuk © (06.09.04 21:22) [49]
to iZEN © (06.09.04 21:14) [48]:
>обмен информацией на основе P2P
Применяется ли это еще где-нибудь, кроме P2P? Имелось в виду именно это.
*/
Что конкретно? MVC в P2P? БД в P2P? что_то кроме P2P?
Не понял.

P2P - это связь станция<->станция. Маршрутизаторы в сетях TCP/IP обмениваются информацией по тому же принципу.

И ещё, немножко статей о P2P: http://www.javable.com/columns/p2p/

> Игорь Шевченко ©
А теперь главный вопрос вопросов - а на фига эти сложности?
В общем-то, я подозреваю, что не от не фиг делать, и всем будет интересно, на каком классе задач это нужно

> [55] iZEN © (06.09.04 23:49)

Все те области применения, которые вы приводите, не гарантируют клиенту ничего, и это не страшно в данном случае. Ну не скачал я файл наспером ввиду недоступности (по одной из 335 причин) одной из станций - ну и ладно. Завтра авось повезет.

Но как вы предполагаете в такой архитекторе следить за уникальностью ключей? За обеспечением ссылочной целостности? При том, что каждая станция может в любой момент отвалиться, зависнуть, перегнить кабель и т.п., в том числе и в момент процедуры синхронизации? И обеспечить надежность такой системы во много раз сложнее, нежели одного отдельно взятого физического сервера.

Так о какой надежности хранения и непротиворечивости данных может идти тут речь??

Теперь ко всем: я так и не понял немного автора вопроса. Из какого набора вариантов выбор предлагается сделать (обоснованный) I или II:
I
а) использовать объектный подход
б) не использоват объекты
II
а) редактировать непосдерственно DataSet
б) на клиенте как-то хранить редактируемые данные, а потом как-то их передавать на сервер (в хранилице) "ручками" (при этом не суть важно на клиенте объекты или некий ClientDataSet)

Поделюсь своим небольшим опытом.
ПО специфике работы часто приходится реализовывать редактирование данных непосредственно в Grid. Т.е. о проблемах одновления непосредственно DataSet знаю не по наслышке.
Вообще стараюсь сейчас от этого уходить, реализовывать сохранение в БД ручками. Т.к. часто возникают огромные проблемы с сохранением записи автоматическими средствами, побеждать которые учень трудно. Я уже не говорю о проблемах проверки корректности данных с выдачей понятной оператору диагностики - это вообще отдельная песня. Тем более когда работа с БД идет через SP - вообще гаси свет.
В простейших случаях (редактирование одной таблицы) однако подход с DB-aware компонентами позволяет существенно ускорить работу. Но как только нужна минимальная проверка и т.п. - все, туши свет.

Заметьте, я не говорю ни о каких объектах, т.е. не затрагиваю проблему как именно храню/обрабатываю данные, редактируемые оператором. Т.е. для меня проблема выбора - это II. В I - это не проблема в том смысле, что тут наворотить можно что хочешь, все равно никто тебя не ограничивает (кроме времени). А вот во второй делеме - тут есть внешние ограничители определенной, не поддающейся изменению логики, зашитой в VCL.

← →
Sergey_Masloff (2004-09-07 09:28) [58]

Игорь Шевченко © (06.09.04 22:16) [51]
Sergey_Masloff (06.09.04 18:55) [35]

>Да, в этом случае, наверное, имеет смысл завести кэш нужных >объектов, которые могут модифицироваться из разных мест.
Так и сделано

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

>Методов реализации кэша данных тоже есть и разных.
Да это понятно. Но получается в любом случае сложная логика.
То есть (например при поиске):
1) Лезем в базу и ищем допустим ИВАНОВА
2) Получаем список который нужно показать пользователю чтобы он выбрал конкретного ИВАНОВА ИВАНА
3) Проверить есть ли он в кэше
4) Если есть то увеличить ему счетчик ссылок если нет то поднять в кэш
5) Дать команду на отображение данных

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

Основной же сложностью для меня еще раз скажу является операция которая изменяет (по определению) состояние объекта в базе.

Пример:
VIEW DOCUMENT DBLAYER STORAGE
Пользователь->Вызвана команда-> Обращение -> Выполнение ХП
ввел число и Calculate() к XP Calc()
нажал расчет

И потом обратный ход -> Документ после Calculate() должен
снова поднять себя из базы (так как он не может знать что конкретно изменилось в базе) -> После этого нужно обновлять VIEW
Вобщем получается накладно. Сейчас это работает но проект имеет тенденции к еще более усложненной схеме и вобщем трудозатраты растут.
Все чего бы я пока хочу - просто отделить VIEW от DOC полностью - но тут же возникает проблема что логика DOC на 80% нигде кроме базы реализована быть не может а тогда зачем он - просто буфер с данными которые потом дублируются при отображении?

> а в главной теме автор кажется хочет отталкиваться от классической
> схемы сервер_БД-клиент.

Да, именно так и стоит задача. Никакой распределенности и раскиданности по городам.

Реализация БД-приложений Найти похожие ветки