On Mar 5, 6:41 pm, Ded <[EMAIL PROTECTED]> wrote:
> Yurij wrote:
> > Складская операция - сложный объект,
> Стоп-стоп-стоп. Тока што объектом была таблица, а операция - это
> как-никак функция...
Тут возникает путаница из-за того, что таблица выполняет несколько
функций -
это и множество записей, и описание их структуры. А класс - это только
структура
объекта. Множество же объектов класса не во всех реализациях ООП
доступно вообще.
> > состоящий из связанных объектов
> И состоит она (информационная реализация) из кода, а не из объектов.
> А материальная реализация состоит из вытаскивания из транспортного
> средства всякой хрени и ракладывания ея по площадям. Тоиссь, как ни
> крути - действие это, а не объект.
Действие раскладывается на его отображения в разных аспектах
информационной системы и поэтому описывается сложным объектом.
Если действие еще и длительное и сложное - то его можно описать
в терминах жизненного цикла объекта, расписать диаграмму состояний,
методы вызывающие переходы, права пользователей на эти методы
и придти в итоге к настраиваемому документообороту.
> > Каждый подобъект в своих методах меняет то к чем относится -
> > накладная, как наследник документа, проходит свои этапы(прием,
> > проведение, итд), движение по складу меняет складские запасы, итд.
> Тока одно без другого не имеет смысла ибо нарушает целостность
> данных. Нет, можно, канешна, пойти на прынцып и размножить и запутать
> код окончательно, но чота не хочется.
На склад могут товары попасть без накладной? Например из торгового
зала
обратно отнесут. Если могут - то уже движение по складу имеет смысл
выносить в отдельный объект.
> > Объекты накладной состоит из шапки(полей объекта)
> > и строк(вложенного списка объектов-строк). Чорт его знает,
> > как автоматически такие объекты отображать на реляционную
> > модель - OR мапперы, hibernate всякие это как-то делают.
> А точно надо?
При проектировании и реализации проще представлять накладную
как один объект, чем как набор из нескольких связанных
записей в нескольких таблицах.
> > Создается или
> > открывается объект "Складская операция", GUI для него генерируется
> > автоматически по описанию объекта,
> Пошол пить иад... Статические у меня гуя, не модно-то как :-( Дурень
> старый, ну нет сделать так, чтоп каждый раз всё само изобреталось,
> проц-то надо же чем-то занимать...
А меня от вида дизайнера форм и мышиной возни начинает бесить. Я
просто
не в состоянии аккуратно расставить 20 полей по форме. Проще
сгенерировать
автоматически - так они гарантированно аккуратное расположение иметь
будут
> > Описание объекта в свою очередь состоит из описания его
> > хранения в СУБД(адаптер объект-СУБД), нескольких вариантов
> > описания его интерфейса(адаптеры GUI,адаптеры веб-интерфейса)
> А теперь ап стенку... Сколько умных слоффффф, мне ж до утра не
> осмыслить...
Это я так разобрал по слоям структуру - объекты с бизнес-логикой
отдельно,
гуи отдельно, сохранение объектов отдельно.
> Не надо, не надо скатываться в косный консервативный примитивизьм!
> Так хорошо начал, а тут - датасет, сиквел :-( Надо этта, извернуться
> как-нить из последних сил, наследование применить. И этот, как его,
> полиморфизьм, вот.
А потому что при любой попытке сделать для объектных баз что-либо
настолько
же удобное, как sql для получения отчетов и списков (фактически -
обработки
множеств объектов), получается либо птичий язык запросов, либо
многословный код
на императивном птичьем языке :)
> Не, ну почему. Ацкесс и дбф - вот мудрость жизни. Или это таки всё
> же тоже СУБД?
Когда к системе, использующей firebird, заставляют подключить еще
старые
системы, писанные на фокспо и кларионе - то там еще и не такое
придумается.
Пределом шизофрении была хранимая процедура, дергающая udf, которая
обращается
к кларионовским таблицам. Скорость работы гораздо выше чем обращение
этим к
таблицам с рабочих мест, так как сервер с fb и файл-сервер с таблицами
были
рядом и соединены гигабитным каналом. И запросы выполнялись на
сервере, а не
данные мотались туда-сюда от клиента к файл-серверу.
