Yurij wrote:
Складская операция - сложный объект,
Стоп-стоп-стоп. Тока што объектом была таблица, а операция - это как-никак функция...
состоящий из связанных объектов
И состоит она (информационная реализация) из кода, а не из объектов. А материальная реализация состоит из вытаскивания из транспортного средства всякой хрени и ракладывания ея по площадям. Тоиссь, как ни крути - действие это, а не объект.
Каждый подобъект в своих методах меняет то к чем относится - накладная, как наследник документа, проходит свои этапы(прием, проведение, итд), движение по складу меняет складские запасы, итд.
Тока одно без другого не имеет смысла ибо нарушает целостность данных. Нет, можно, канешна, пойти на прынцып и размножить и запутать код окончательно, но чота не хочется.
Объекты накладной состоит из шапки(полей объекта) и строк(вложенного списка объектов-строк). Чорт его знает, как автоматически такие объекты отображать на реляционную модель - OR мапперы, hibernate всякие это как-то делают.
А точно надо?
Аггрегированные отображения делать расчетными, считать по мере надобности на сервере приложений, кэшировать, т.е. ленивый расчет.
Можно. И порой удобно, а порой нет.
Т.е. если по хорошему - клиент вообще не касается таблиц, а работает с объектами через сервер приложений.
О. Надо же. Так и есть. Только не из-за ООП, а из-за того, что база центра одна, а комплектационные склады и их АРМы и в Чушке, и в Голландии, и в Питере, и в Ростове и во Владике. Не открывать же порт 3050 :-D
Создается или открывается объект "Складская операция", GUI для него генерируется автоматически по описанию объекта,
Пошол пить иад... Статические у меня гуя, не модно-то как :-( Дурень старый, ну нет сделать так, чтоп каждый раз всё само изобреталось, проц-то надо же чем-то занимать...
Описание объекта в свою очередь состоит из описания его хранения в СУБД(адаптер объект-СУБД), нескольких вариантов описания его интерфейса(адаптеры GUI,адаптеры веб-интерфейса)
А теперь ап стенку... Сколько умных слоффффф, мне ж до утра не осмыслить...
Остается описание списков объектов и отчетов - тут в некоторых случаях хватает обычного датасета, заполняемого sql запросом, а иногда можно еще сверху прицепить обработку какую-нибудь сложную.
Не надо, не надо скатываться в косный консервативный примитивизьм! Так хорошо начал, а тут - датасет, сиквел :-( Надо этта, извернуться как-нить из последних сил, наследование применить. И этот, как его, полиморфизьм, вот.
А, и еще советуют вообще не пользоваться кодом внутри СУБД, типа хранимых процедур - типа "чтобы можно было сервер заменить на другой" Но по-моему, "замена СУБД" это иллюзия :)
Не, ну почему. Ацкесс и дбф - вот мудрость жизни. Или это таки всё же тоже СУБД?
-- Regards. Ded.
