Yurij wrote:
Множество же объектов класса не во всех реализациях ООП доступно вообще.
Не может быть, чтоб в ООП что-то было не то што недоступно, а просто некузяво. Не верю!
Действие раскладывается на его отображения в разных аспектах информационной системы и поэтому описывается сложным объектом.
А я всю жись думал что действие - это 2+2 :(
Если действие еще и длительное и сложное - то его можно описать в терминах жизненного цикла объекта, расписать диаграмму состояний, методы вызывающие переходы, права пользователей на эти методы и придти в итоге к настраиваемому документообороту.
Для этого мне сначала придёццо от него уйти...
На склад могут товары попасть без накладной? Например из торгового зала обратно отнесут. Если могут - то уже движение по складу имеет смысл выносить в отдельный объект.
Накладная есть всего лишь один из видов документов, обуславливающих или инициирующих движение товаров. Обожествлять её не надо. А вот ежели движение товаров осуществляется ваще без всякой причины и документа, обуславливающего-фиксирующего матответсвенность, само собой, то этта, канешна, вышший пилотаж настраиваемого документооборота, до которого мне ышо расти и расти...
При проектировании и реализации проще представлять накладную как один объект, чем как набор из нескольких связанных записей в нескольких таблицах.
Ну и представляй на здоровье. Это действительно один, только докУмент, а не объект. Хранящийся в нескольких записях в связанных таблицах. И даже, страшно себе представить, ссылающихся походу на туеву хучу справочников...
Я просто не в состоянии аккуратно расставить 20 полей по форме.
Сочувствую. Кстате, знаю несколько прекрасных психоаналитиков...
Проще сгенерировать автоматически - так они гарантированно аккуратное расположение иметь будут
Аккуратное - это в смысле симметричное? А про науку эргономику мсье чонить слыхал? Типа штоп удобно глазками было охватывать зАраз то, что нужно для выполнения определённых информационных функций? И чтоп курсор по табу прыгал куда удобно при выполнении этих самых функций, а не обязательно слева направо? И ещё всяко-разно из этой области?
Это я так разобрал по слоям структуру - объекты с бизнес-логикой отдельно, гуи отдельно, сохранение объектов отдельно.
Ааааа... Не, тут я поддерживаю. Обънкты с бизнес-логикой в гуях хранить, право, несподручно...
А потому что при любой попытке сделать для объектных баз что-либо настолько же удобное, как sql для получения отчетов и списков (фактически - обработки множеств объектов), получается либо птичий язык запросов, либо многословный код на императивном птичьем языке :)
Тогда - ОВСФ? > Пределом шизофрении была хранимая процедура, дергающая udf, которая
обращается к кларионовским таблицам. Скорость работы гораздо выше чем обращение этим к таблицам с рабочих мест, так как сервер с fb и файл-сервер с таблицами были рядом и соединены гигабитным каналом. И запросы выполнялись на сервере, а не данные мотались туда-сюда от клиента к файл-серверу.
О, знакомые слова и аргументы пошли - быстродействие, эффективность... Ничего извращённого я в них не вижу :)
-- Regards. Ded.
