Здравствуйте, 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% можно переписать и вручную.
Мы уже победили, просто это еще не так заметно...
