Здравствуйте, dshe, Вы писали:
D>Интересуют различные мнения по поводу Naked Objects (как подхода в целом, так и одноименного framework'а)
Мнение Фаулера (AnemicDomainModel) интересно?
The user interface should be a direct representation of the domain objects
The user interface should be created 100% automatically from the definition of the domain objects.
Direct Representation это... ммм... да вобщем оно так совсем не всегда бывает. Боюсь, что по сложившейся традиции программисты решат, что юзеры — идиоты и сделают самую хорошую ОО модель (которую сами же потом назовут неправильной и пару раз переделают), а вот интерфейс получится неадекватным.
A>Почитал определение
A>The user interface should be a direct representation of the domain objects A>The user interface should be created 100% automatically from the definition of the domain objects.
A>Direct Representation это... ммм... да вобщем оно так совсем не всегда бывает. Боюсь, что по сложившейся традиции программисты решат, что юзеры — идиоты и сделают самую хорошую ОО модель (которую сами же потом назовут неправильной и пару раз переделают), а вот интерфейс получится неадекватным.
В общем, согласен, что если пользовательский интерфейс генерить из голой объектной модели, то он скорее всего получится убогим.
Но, имхо, если этот подход немного развить — может получиться вполне жизнеспособное решение.
Развить можно примерно так: в описание предметной области, помимо самих объектов, включить разнообразные хинты, подсказывающие, как лучше эти объекты отображать в интерфейсе (подчеркиваю: хинты — это только данные, никакого кода!) Например, если объект класса A содержит список объектов класса B, одним из таких хинтов может служить предполагаемое среднее число элементов в этом списке, пользуясь этим хинтом генератор UI может решить, как лучше отобразить объекты B — каждый на отдельной форме или весь список на той же форме, что и объект A.
Если придумать хорошую систему таких хинтов, то в результате ГУИ может получтиться вполне приличным (но это все равно не значит, что программы будут писаться взмахом волшебной палочки — т.к. при построении модели предметной области надо будет грамотно расставить все хинты). Зато по одной модели можно будет генерить разные типы интерфейсов — например, классический клиент и веб-интерфейс
P.S. Нечто аналогичное вовсю используется для генерации структуры базы из модели предметной области.
Интересная тема, посмотрю, пока из того что понял по верхам ... немного пытаюсь копать в сторону XML Schema -> XML Forms + Native XML Databse. Здесь посмотрел на интересную систему. В общем XSD + несколько XSL и XQuery с возможностью создания промежуточных расширений для доводки выходных форм.
Много программировал различные OLTP приложения, и пытался крутить тему таблиц и записей реляционных БД. На самом деле как не посмотри получаются таблицы и формы редактирования, а их действительно можно сделать довольно просто на основе модели. Select/Insert/Update/Delete ... и тема как раз продолжается в ROX/X2O для XML Schema.
Для БД пришел к выводу, что все и в правду довольно просто (если не брать сервисы, типа печати, настройки колонок, фильтрации — там тоже не сложно — просто для упрощения). Есть объекты модели — запись и таблица, соответственно есть вьюверы для таблицы и для записи. Все это дело можно комбинировать, настраивать для различных экземпляров различные вьюверы ...
Здравствуйте, nvoynov, Вы писали:
N>Для БД пришел к выводу, что все и в правду довольно просто (если не брать сервисы, типа печати, настройки колонок, фильтрации — там тоже не сложно — просто для упрощения). Есть объекты модели — запись и таблица, соответственно есть вьюверы для таблицы и для записи. Все это дело можно комбинировать, настраивать для различных экземпляров различные вьюверы ...
ага, и получаем "1С: Урод на предприятии" с друзьями и сотоварищами. Спасибо, насмотрелся. Кому таблицы в БД, а кому предметная область.
Здравствуйте, adontz, Вы писали:
A>ага, и получаем "1С: Урод на предприятии" с друзьями и сотоварищами. Спасибо, насмотрелся. Кому таблицы в БД, а кому предметная область.
Хотелось бы посмотреть на вашу предметную область, имеем в виду слой domain, можно кусочек для примера? То что она влезет в БД это 100%, вопрос хорошо влезет или плохо, если плохо и предметная область сложна, то ORM должен спасать.
Да кто его знает — у вас одна правда, у 1С другая — и обе они правильные Таблицы БД просто отражение модели предметной области для постоянного хранения. Я не большой дока в ORM, не пользовался и пока необходимости не возникало. ООП я знаю и конечно же использую (на уровне приложения, типа модулей, различных сервисов — почта, сортировка, поиск, ...), но привычка сначала моделировать данные еще никогда не подводила (построено пяток серьезных OLTP приложений). Функциональное моделирование и моделирование данных до сих пор успешно существуют вместе. И в предложенном фреймворке как раз такая же тема — отдельно данные и отдельно функции, которые с этими данными работают, отдельно настраиваемое представление. Не делаете ли вы тоже самое — DB-DOMAIN-UI — абсолютно тоже самое, только по другому!?
Здравствуйте, nvoynov, Вы писали:
A>>ага, и получаем "1С: Урод на предприятии" с друзьями и сотоварищами. Спасибо, насмотрелся. Кому таблицы в БД, а кому предметная область.
N>Хотелось бы посмотреть на вашу предметную область, имеем в виду слой domain, можно кусочек для примера?
Предметная область не суть, суть в том, что нельзя строить интерфейс когда в голове таблицы. Простой пример из непосредственно сегодняшней практики. На работе стоит программа XYZ фирмы Microsoft слегка доделанная литовцами и, в последствии, местными. Для выбора человека, есть поле в которое надо ввести его идентификационный. Коды наизусть, естественно, никто не помнит, таким образом, чтобы ввести код надо нажать <Enter>. Это уже плохо, потому что мне не надо нажимать <Enter> и что-то делать во вновь открывшемся окне, мне нужно вводить вручную с очень умным автодополнением. Впрочем это не суть. По <Enter> открывается не модальное окно, а новый документ(!) в котором фактически вся таблица с пользователями. Поиска никакого, нажимаем клавишу <стрелка вниз> пока не найдём нужную строку, потом кнопку внизу Select. То есть формально-то нужная функциональность есть, но это никакая не нормальная реализация, это дилетантство и халтура в стиле "1С:Урод на предприятии".
А ещё если выбрать валютный счёт, но сумму указать в евро, то выдаётся очень понятное сообщения об ошибке в Primary Key. Зачем мне вообще вводить валюту если она уже указана в счёте номер которого я ввёл до того? Потому что в таблице куда делается запись есть такой столбец?
Забудьте про БД когда делаете интерфейсы! Совсем! Нет никаких таблиц, нет никаких столбцов, есть живые люди, запоминающие не цифры и коды, а имена и названия, у них только 10 пальцев и большинство печатает всего четырьмя или пятью. Им надо быстро работать, набирать только необходимый минимум информации самым удобным способом. Я знаю Нино и Георгия, я не знаю кто такие VS06378 и PS83221. Зачем мне где-то видеть, тем более вводить внутренний для программы идентификационный номер?! Долой генераторы интерфейсов, долой халтуру и лентяев! Выкиньте из головы БД к чёртовой бабушке!
Здравствуйте, adontz, Вы писали:
A>Забудьте про БД когда делаете интерфейсы! Совсем! Нет никаких таблиц, нет никаких столбцов, есть живые люди, запоминающие не цифры и коды, а имена и названия, у них только 10 пальцев и большинство печатает всего четырьмя или пятью. Им надо быстро работать, набирать только необходимый минимум информации самым удобным способом. Я знаю Нино и Георгия, я не знаю кто такие VS06378 и PS83221. Зачем мне где-то видеть, тем более вводить внутренний для программы идентификационный номер?! Долой генераторы интерфейсов, долой халтуру и лентяев! Выкиньте из головы БД к чёртовой бабушке!
Зачем что-то выкидывать??
С чего ты взял, что автосгенерированый интерфейс будет требовать ручное введение кодов, а не красивый выбор из списка с автодополнением. Генератору на это можно указать наличием нужных FK или расстановкой хинтов.
Здравствуйте, Cyberax, Вы писали:
C>С чего ты взял, что автосгенерированый интерфейс будет требовать ручное введение кодов, а не красивый выбор из списка с автодополнением. Генератору на это можно указать наличием нужных FK или расстановкой хинтов.
Да тут такое дело, что я хочу чтобы садился код человека, а вот в списке была фамилия или имя или номер автомобиля на котором он ездит и если я начал набирать Геор то пусть в списке будут только имена, а если BD, то только номера автомобилей.
Боюсь потребуется столько разных подсказок (как много типов подсказок, так и много экземпляров), что в итоге проще это сделать руками, чем сперва делать генератор, а потом пытаться его использовать. Есть области в автоматизацию которых я пока что верю с трудом.
Здравствуйте, adontz, Вы писали:
A>Да тут такое дело, что я хочу чтобы садился код человека, а вот в списке была фамилия или имя или номер автомобиля на котором он ездит и если я начал набирать Геор то пусть в списке будут только имена, а если BD, то только номера автомобилей.
Зачем тебе вообще выбирать код? Тебе надо выбирать человека, сам по себе код будет бесполезен (если, конечно, он не используется для каких-то внешних действий, типа поиска в шкафу с документами).
А то, что ты говоришь, обычно просто можно сделать, если искать по всем столбцам таблицы. Например, в моем приложении для поиска человека "Paul Johnson из Florida" ты в строке поиска можешь написать "pau j flo". Это делается поверх стандартной табличной модели, так что вполне доступно автогенератору.
Здравствуйте, adontz, Вы писали:
A>Предметная область не суть, суть в том, что нельзя строить интерфейс когда в голове таблицы.
A>Забудьте про БД когда делаете интерфейсы! Совсем! Нет никаких таблиц, нет никаких столбцов, есть живые люди, запоминающие не цифры и коды, а имена и названия, у них только 10 пальцев и большинство печатает всего четырьмя или пятью. Им надо быстро работать, набирать только необходимый минимум информации самым удобным способом ... Долой генераторы интерфейсов, долой халтуру и лентяев! Выкиньте из головы БД к чёртовой бабушке!
Может броневичок подогнать? Шутка, однако кроме пользователя есть еще и простое правильное структурирование информации. В голове не таблицы — в голове клиент, номер счета, дата ... коллекция позиций по счету. Заметим, что на то он и генератор, чтобы генерить. Как генерить зависит только от разработчика. Если разработчик делает третий раз одно и тоже — нужно пересмотреть способы своей работы. Халтура заключается как раз в том, чтобы этого не замечать и делать одно и тоже снова и снова, не замечать что "все одинаково — рост, вес .. кроме одного — анкетных данных.. в маленьких буковках ... скажите, разве дело в буковках"
Если подитожить — XYZ, MS и литовцы все-таки не показатель. Речь не идет о всей работе, а о 90% работы дурной.
Здравствуйте, Cyberax, Вы писали:
C>Зачем тебе вообще выбирать код? Тебе надо выбирать человека, сам по себе код будет бесполезен (если, конечно, он не используется для каких-то внешних действий, типа поиска в шкафу с документами).
Ну его потом нудно вставить. Со скрытыми полями ввода там косячок...
C>А то, что ты говоришь, обычно просто можно сделать, если искать по всем столбцам таблицы. Например, в моем приложении для поиска человека "Paul Johnson из Florida" ты в строке поиска можешь написать "pau j flo". Это делается поверх стандартной табличной модели, так что вполне доступно автогенератору.
Доступно вовсе не означает что конкретный генератор это будет уметь. Добавь сюда локализацию. Добавь тот факт, что pu j flo, j pau flo и flo pau j лично в моём понимании варианты равноправные абсолютно. Вобщем оно только в теории хорошо.
Здравствуйте, nvoynov, Вы писали:
N>Может броневичок подогнать? Шутка, однако кроме пользователя есть еще и простое правильное структурирование информации. В голове не таблицы — в голове клиент, номер счета, дата ... коллекция позиций по счету. Заметим, что на то он и генератор, чтобы генерить. Как генерить зависит только от разработчика. Если разработчик делает третий раз одно и тоже — нужно пересмотреть способы своей работы. Халтура заключается как раз в том, чтобы этого не замечать и делать одно и тоже снова и снова, не замечать что "все одинаково — рост, вес .. кроме одного — анкетных данных.. в маленьких буковках ... скажите, разве дело в буковках"
N>Если подитожить — XYZ, MS и литовцы все-таки не показатель. Речь не идет о всей работе, а о 90% работы дурной.
У тебя не генератор, а управляемый ИИ вышел. Уверен что оно правда есть?
Здравствуйте, adontz, Вы писали:
A>У тебя не генератор, а управляемый ИИ вышел. Уверен что оно правда есть?
Я просто не люблю делать одну и туже работу несколько раз — меня это всегда настораживает и двигает искать способы избежать лишней работы и потратить время на более интересные вещи. И, повторюсь, большую часть интерфейсов все-таки можно сгенерировать. Рекомендую посмотреть еще в тему одну статейку и описываемый проект: http://www.xml.com/lpt/a/1714 http://code.google.com/p/x2o/
Здравствуйте, nvoynov, Вы писали:
N>И, повторюсь, большую часть интерфейсов все-таки можно сгенерировать.
Да беда в том, что никто не станет генерировать большую часть. В 1С то же есть редактор форм. Ну не пользуется им никто, все лентяи и бороться с этим решительно некому, потому что это же надо каждую формочку просмотреть и подумать, а можно ли лучше и стоит ли оно того. В итоге на самом деле даже этот анализ того не стоит и генерация интерфейса подобно цепной реакции распространяется по проекту захватывая все его части. Всем хочется не работать, а руководить, пусть и генератором. Всем хочется чтоб было аккуратно и быстро, а то что пользователь смотря на форму ничего не понимает, так это проблема Help Desk, а не программистов. Не работает принцип "давайте сгенерируем только то, что действительно стоит" в реальной жизни.
Здравствуйте, adontz, Вы писали:
C>>А то, что ты говоришь, обычно просто можно сделать, если искать по всем столбцам таблицы. Например, в моем приложении для поиска человека "Paul Johnson из Florida" ты в строке поиска можешь написать "pau j flo". Это делается поверх стандартной табличной модели, так что вполне доступно автогенератору. A>Доступно вовсе не означает что конкретный генератор это будет уметь.
Проблемы генератора. Ручная реализация тоже может не уметь.
A>Добавь сюда локализацию.
Language-neutral, кроме экзотики со сложными написаниями символов.
A>Добавь тот факт, что pu j flo, j pau flo и flo pau j лично в моём понимании варианты равноправные абсолютно. Вобщем оно только в теории хорошо.
Да, ты можешь в любом порядке вводить. Смысл в том, что ты видишь результаты фильтрации интерактивно.
Да, и в любом случае, если генератор будет реализовывать 90% рутинных операций — то оставшиеся 10% можно переписать и вручную.
Здравствуйте, nvoynov, Вы писали: N>Да кто его знает — у вас одна правда, у 1С другая — и обе они правильные Таблицы БД просто отражение модели предметной области для постоянного хранения. Я не большой дока в ORM, не пользовался и пока необходимости не возникало. ООП я знаю и конечно же использую (на уровне приложения, типа модулей, различных сервисов — почта, сортировка, поиск, ...), но привычка сначала моделировать данные еще никогда не подводила (построено пяток серьезных OLTP приложений). Функциональное моделирование и моделирование данных до сих пор успешно существуют вместе. И в предложенном фреймворке как раз такая же тема — отдельно данные и отдельно функции, которые с этими данными работают, отдельно настраиваемое представление. Не делаете ли вы тоже самое — DB-DOMAIN-UI — абсолютно тоже самое, только по другому!?
Нет. Таблицы БД никакую предметную область не отражают. Они отражают некоторую модель, причем модель структуры информации. Эта модель совершенно необязательно соответствует модели, которая в голове у пользователя.
Приведу жизненный пример: формирование заказа. Классическая задача. Решена миллион раз. При словах "формирование заказа" опытный программист корпоративного софта сразу представляет себе что-то вроде OrderDetail(OrderID foreign key referernces Orders.ID, ItemID foreign key references Items.ID, quantity decimal not null).
Следом сразу же колбасится интерфейс Master-detail; где ессно ItemID выбирается из DropDown (патамушто foreign key) и так далее.
С ростом объема прайслиста дропдаун превращается в диалог а-ля File Open, и хорошо еще, если он хотя бы запоминает последнюю позицию в каталоге.
Потом сеньор депелопер лепит фреймворк, который шлепает такой UI по структуре таблиц (плюс несложные хинты) автоматически. Он может даже научить UI поддерживать драг-н-дроп из каталога в заказ и наоборот.
Когда мы переходим в реальность оптовой выписки, оказывается, что как правило клиент делает заказ совсем не так, как программист покупает себе монитор. Он оперирует распечаткой прайс листа, напротив каждой позиции он ставит количество. И с этой распечаткой он приходит (а то и присылает по факсу) делать свой заказ.
И самым эффективным становится интерфейс, который представляет заказ не как select * from OrderDetail where OrderID=@OrderID, а как полный прайс лист с проставленными количествами по каждой позиции. Девочка "бежит" по списку со скоростью порядка 20 позиций в секунду, изредка останавливаясь, чтобы вбить количество в ту единственную ячейку, которая ей нужна. Она руками помнит количество нажатий PageDown и DownArrow, чтобы добраться до "Соус хайнц н43 200стб". Ей банально быстрее пропустить 20 ненужных позиций, чем выбрать одну нужную через наш мегаавтокомплит.
Никакой генератор UI вам это не сгенерирует. Более того, вы никогда об этом не задумаетесь, пока будете мыслить в терминах табличек и связей, а не процессов и информации.
Об этом пишет Рома. Об этом пишут авторы Inductive UI.
Да, иногда можно применять тупой механический подход. Большинство справочников мы так или иначе редактируем всё в том же гриде, до боли знакомом мне еще по Clipper'87.
Но это не потому, что природа такова. Это потому, что у нас нет ресурсов выяснить, какие именно задачи решают пользователи чаще всего.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
С заказом согласен на много процентов. Сам делал несколько реализаций и первая была именно беготней по списку позиций ... набираешь часть названия и получаешь позиционирование на позиции или фильтрацию; вбиваешь количество и идешь дальше к следующей позиции ... считаются суммы; когда заказ набран он формируется дальше. Хочется отметить что на этом с самого начала настаивал заказчик ...98 год... софт работает без особых изменений по сегодняший день и никто пока не отменил принятого подхода... И реализовано было стандартным образом — торчал один и тот же фрейм, чем не генератор? Я о том и говорю
Второй софт делал немного не так — там были работы выполненные в рамках проекта. Отмечались работы и на их основе формировался счет, но это не отменяло и возможности ручного добавления/удаления работ. При этом налоги и скидки все-таки выбирались из дроп-боксов...
Следующая софтина работала с каталогом в 120000 позиций и 2000000 предложений, применялся подход похожий к 1, только вываливался уточняющий диалог. Все равно реализация механизма везде была одна и таже!
Т.е. основная мысль — критика ваша просто не принимается когда вы можете конфигурировать View часть MVC своими реализациями.
Здравствуйте, nvoynov, Вы писали:
N>Т.е. основная мысль — критика ваша просто не принимается когда вы можете конфигурировать View часть MVC своими реализациями.
Вот как раз основная мысль совершенно непонятна. Уточните мне, по каким таблицам вы собираетесь генерировать этот view?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > Никакой генератор UI вам это не сгенерирует. Более того, вы никогда об > этом не задумаетесь, пока будете мыслить в терминах табличек и связей, а > не процессов и информации.
Представь себе, как раз на прошлой неделе решили примерно такую же
задачу (точнее, несколько проще — нам не надо было количество
указывать). В виде нового плугина к генератору UI.
Какие проблемы-то? Понятно, что иногда будут требоваться нестандартные
решения, но никто же не мешает их сделать custom-но или добавить их в
генератор.
Здравствуйте, Cyberax, Вы писали: C>Какие проблемы-то? Понятно, что иногда будут требоваться нестандартные C>решения, но никто же не мешает их сделать custom-но или добавить их в C>генератор.
Ну, я наверное паталогически туп. Я не понимаю, как генератор будет генерировать UI по отсутствуюшим в природе метаданным.
Пример я привел. Я понимаю, что прикрутить всё руками можно. Но я не понимаю, каким образом генератор сгенерирует всё самостоятельно.
Точнее, я представляю себе, что наверное для моего случая можно прикрутить соответствующий view, который будет чудовищным образом мерджить OrderItem с PriceListItem; но это уже получается попытка реализовать концептуальную модель взамен модели данных. На всякий случай напомню, что мы обсуждаем построение UI по модели данных. А не построение UI автоматическими генераторами в широком смысле. Под последнее вообще можно подвести всё что угодно, кроме разве что ручного размещения контролов по позициям и выполнения message pump.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote: > C>Какие проблемы-то? Понятно, что иногда будут требоваться нестандартные > C>решения, но никто же не мешает их сделать custom-но или добавить их в > C>генератор. > Ну, я наверное паталогически туп. Я не понимаю, как генератор будет > генерировать UI по отсутствуюшим в природе метаданным. > Пример я привел. Я понимаю, что прикрутить всё /руками/ можно. Но я не > понимаю, каким образом генератор сгенерирует всё самостоятельно.
У нас это управляется внешним XMLем — в нем описывается layout контролов
и их привязка к модели. В модели есть примерно следующее:
public class Week
{
Set<Shift> shifts;
}
Человеку нужно этот вот Set сформировать. Во внешнем XMLе указано, что
нужно сделать список с checkbox'ами для этого Set'а. Ну генератор это и
делает.
На твой пример расширяется совершенно понятным образом.
Здравствуйте, Cyberax, Вы писали: C>У нас это управляется внешним XMLем — в нем описывается layout контролов C>и их привязка к модели. В модели есть примерно следующее: C>
C>public class Week
C>{
C> Set<Shift> shifts;
C>}
C>
C>Человеку нужно этот вот Set сформировать.
Ну то есть я надеюсь, что хоть к этому моменту стало понятно, что это нифига не storage модель? Внешний XML, модель, которую программист формирует руками... Ну и что осталось от DDL?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
C>>public class Week
C>>{
C>> Set<Shift> shifts;
C>>}
C>>
C>>Человеку нужно этот вот Set сформировать. S>Ну то есть я надеюсь, что хоть к этому моменту стало понятно, что это нифига не storage модель?
Почему же? Вполне storage-модель. Это классы, которые отображаются в БД с помощью Hibernate. В файлах mapping'а Hibernate'а, конечно, есть некоторая дополнительная информация по сравнению с простыми констрейнтами БД, но это все равно остается storage model.
S>Внешний XML, модель, которую программист формирует руками... Ну и что осталось от DDL?
С помощью XML даются хинты (в сколько колонок расположить, порядок элементов и т.п.).
Здравствуйте, Cyberax, Вы писали: C>Почему же? Вполне storage-модель. Это классы, которые отображаются в БД с помощью Hibernate. В файлах mapping'а Hibernate'а, конечно, есть некоторая дополнительная информация по сравнению с простыми констрейнтами БД, но это все равно остается storage model.
Я, наверное совсем тупой. Я не понимаю, что такое Set<Shifts>, и для чего генератор проставит галочки. Для каждого шифта в сете? Откуда возьмутся UI элементы для данных, которых в сете нету?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>Почему же? Вполне storage-модель. Это классы, которые отображаются в БД с помощью Hibernate. В файлах mapping'а Hibernate'а, конечно, есть некоторая дополнительная информация по сравнению с простыми констрейнтами БД, но это все равно остается storage model. S>Я, наверное совсем тупой. Я не понимаю, что такое Set<Shifts>, и для чего генератор проставит галочки. Для каждого шифта в сете? Откуда возьмутся UI элементы для данных, которых в сете нету?
Set<Shift> — это множество результатов, которые надо выбрать. Они выбираются из множества доступных Shift'ов в текущем контексте (сложно объяснять — специфика приложения).
C>Set<Shift> — это множество результатов, которые надо выбрать. Они выбираются из множества доступных Shift'ов в текущем контексте (сложно объяснять — специфика приложения).
Ну а галочки-то напротив чего ставятся? Напротив шифтов текущего контекста, так? Ну и какая же это модель данных? текущий контекст — штука умозрительная, так же как и"прайслист с количествами". А раз умозрительная — значит описана где-то еще, не в модели данных.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
C>>Set<Shift> — это множество результатов, которые надо выбрать. Они выбираются из множества доступных Shift'ов в текущем контексте (сложно объяснять — специфика приложения). S>Ну а галочки-то напротив чего ставятся? Напротив шифтов текущего контекста, так? Ну и какая же это модель данных? текущий контекст — штука умозрительная, так же как и"прайслист с количествами". А раз умозрительная — значит описана где-то еще, не в модели данных.
Ну не совсем умозрительная, у нас для описания контекста используется что-то типа осей в XPath, только они работают на модели данных.
Здравствуйте, Cyberax, Вы писали: C>Ну не совсем умозрительная, у нас для описания контекста используется что-то типа осей в XPath, только они работают на модели данных.
Еще раз: в модели данных нет никаких контекстов. Контексты вы придумываете сами. Модель данных — это в чистом виде Entity-Relation. Это если данные реляционные.
То, что вы описываете в гибернейте — это уже концептуальная модель, и маппинг как раз сшивает между собой модель данных и концепт.
Я не знаю, почему вы так сопротивляетесь этому факту. Что, работа с чем-то кроме модели данных кажется неприличной?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, nvoynov, Вы писали:
N>... да еще пришло в голову два слова MDA и ECO (реализация MDA от борланд) вот бы еще специалистов по этим темам услышать
Я работал не с eco, а с Bold — это мда для делфи, собственно предшественник эко.
Очень удобно. Особенно на начальном этапе проекта, когда нужно написать много кода и производительность не самое главное.
Мы уже победили, просто это еще не так заметно...
