Будущее шаблона Naked Objects (и автогенерация пользовательского интерфейса)

Ответ 1

Да, я считаю, что концепция автогенерируемых приложений на основе метаданных очень проста - главным образом потому, что она значительно сокращает время разработки и улучшает качество кода за счет уменьшения массивной избыточности, которую вы имеете в большинстве приложений, где каждое поле данных домена представлено в базы данных, в модели, в пользовательском интерфейсе и часто также несколько раз в разных слоях отображения.

Я думаю, что будущее - это автоматически созданные приложения, которые могут быть изменены везде, где это необходимо. В настоящее время это AFAIK действительно невозможно; например, Rails позволяет полностью настраивать пользовательский интерфейс при использовании статических строительных лесов, что в основном означает создание кода, т.е. многие дальнейшие изменения в модели домена затем автоматически не отображаются в пользовательском интерфейсе, поскольку дублирование произошло, когда код был сгенерирован.

Я считаю, что первая структура, которая впоследствии сможет сочетать полное автогенерирование с полной изменчивостью, станет стандартом де-факто развития до ранее неизвестной степени. Хотя, скорее всего, мы попадем туда небольшими шагами, чтобы не было такой единой доминирующей структуры.

Ответ 2

Взгляните на JMatter, что является более реалистичной реализацией Naked Objects.

http://www.jmatter.org

Существует также Крис Мюллер, работающий над MAUI, а Лукас Рэнгли работает над Магриттом (оба Squeak/Smalltalk)

У нас есть много сгенерированного пользовательского интерфейса в части конфигурации наших приложений. Все эти списки, которые существуют навсегда и меняются один раз в голубой луне системным администратором.

Я нахожу, что большинство приложений с бэк-сервером базы данных имеют плохой дизайн от перспективы OO и NO, как уже показано в книге NO от Pawson и Matthews.

Ответ 3

Re: qn # 1... Вы верите в концепцию автогенерации пользовательского интерфейса из метаданных?... Я определенно собираюсь ответить "да" на ваш первый вопрос, будучи одним из коммиттеров в платформу Naked Objects (Java) и написав книгу о DDD + NO.

В вопросе упоминаются метаданные. Я думаю, что это ключ к тому, чтобы НЕТ не удалось добиться успеха. В последней версии (которая пройдет бета-версия в феврале) метамодель открывается, так что она очень расширяема, так что вы можете написать свою модель домена, следуя своим собственным соглашениям/аннотациям программирования, или, возможно, чтобы более сложные зрители могут искать свои собственные метаданные для предоставления более сложных представлений. (Например, учтите, что если объект реализовал интерфейс местоположения, то он отображается на картах google).

Что касается qn # 2... к каким проблемам можно подойти таким образом... мы всегда говорили, что NO больше подходит для "суверенных приложений" (транзакционные, операционные системы, используемые внутри организации), чтобы "переходные приложения" (например, киоск аэропорта). НЕТ GUI требует, чтобы пользователь был знаком с доменом, иначе они не будут знать, что они ищут.

Конечно, пропавших без вести сложно увлеченных зрителей. Вы правы относительно НЕТ GUI, это определенно низкая точность (хотя версия .NET является большим улучшением, см. Недавнюю статью infoq.com). На стороне Java есть сестра проекта scimpi.org, который имеет многообещающий, хотя... он предоставляет базовый веб-графический интерфейс бесплатно, но позволяет вам обрабатывать веб-страницы по мере необходимости и постепенно. Я также работаю над графическим интерфейсом Eclipse RCP, который будет работать аналогичным образом.

Другое дело, чтобы добавить к этому, однако, что подход NO имеет ценность (я считаю), даже если вы решите написать пользовательский графический интерфейс и/или уровень представления. То есть вы можете использовать его в качестве инструмента проектирования для создания очень прочного домена домена pojo, а затем скрыть его, как вы. Проблема в том, что NO никогда не был первоначально продан в этих условиях, поэтому большинство из них увидит шаблон NO как дело "все или ничего".

Dan

Ответ 4

Один из способов взглянуть на это - рассмотреть разницу между пользовательским интерфейсом, который вы получаете от чего-то вроде Toad или MySQL Browser, где пользовательский интерфейс напрямую построен из таблиц и связанных с ними метаданных, а также интерфейс пользователя, который опытный дизайнер разработал бы для фактического применения. ЕСЛИ это не слишком несравнимо, тогда это должно быть довольно плотно приподнятым фруктом для рамки автогенерации.

Как вы говорите, есть классы проблем, которые будут хорошо работать с таким автогенератором, а некоторые из них не будут. На мой взгляд, ключевые моменты в том, насколько хорошо модель реализации (или ее часть), которую вы просматриваете в пользовательском интерфейсе, сопоставляется с концептуальной моделью пользователя. Во-вторых, насколько хорошо поведение приложения может быть выражено через ограниченный набор компонентов пользовательского интерфейса (при условии, что это универсальная среда формирования пользовательского интерфейса).

Эта статья " Универсальная модель пользовательского интерфейса" может представлять интерес.

Ответ 5

Я думаю, что идея автоматически создаваемых пользовательских интерфейсов имеет большой потенциал, особенно для вашего среднего пользовательского интерфейса базы данных формы и таблицы. Однако даже там человек должен находиться в цикле, имея возможность переопределять вывод, не перезаписывая его следующей регенерацией.

Я подозреваю, что автоматически создаваемые пользовательские интерфейсы будут более успешными сегодня, если разработчики взаимодействия будут более активно участвовать в разработке алгоритмов генерации. Мое впечатление состоит в том, что исторически создатели этих систем не знают, какие метаданные, связанные с пользовательским интерфейсом, включают или как их использовать. Задание меток, диапазонов значений, форматов и заказов для полей - это начало, но требуется более высокая информация. Достаточное моделирование задач и пользовательских ролей в частности, как правило, отсутствует, наряду с некоторыми базовыми принципами стиля руководства для пользовательского интерфейса.

Oracles Designer 2000, например, был на правильном пути, включая не только сущности и отношения в модели, но и задачи в виде функциональной иерархии. Затем они взорвали его, неправильно применяя эти метаданные (например, считая, что глубина всегда предпочтительна для широты) и включая фундаментальные недостатки при создании пользовательского интерфейса (например, только одно первичное окно может быть открыто за раз). Результатом явились МС, которые даже не были совместимы с собственными стандартами пользовательского интерфейса Oracles.

Ответ 6

Получение базового пользовательского интерфейса быстро, который позволяет клиенту попробовать систему и создать тестовые данные. Рамки Naked Objects могут помочь для < привязки для загрузки ", даже если вы должны заменить его интерфейсом" ручной работы "перед отправкой.

В большинстве систем, над которыми я работал, было много простых таблиц ведения домашнего хозяйства. Все эти таблицы нуждаются в пользовательском интерфейсе для редактирования и просмотра их и т.д. В этих простых редакторах также важна согласованность. Здесь структура обнаженных объектов могла бы сэкономить много времени, даже если основной пользовательский интерфейс "день за днем" "ручной"

Ответ 7

Я видел пару неудачных проектов (случаи, когда меня привлекали как довольно дорогого консультанта, чтобы помочь архитектору заменить), который использовал подход "голые объекты" (а не рамки, AFAIK) - все с просто ужасающими пользовательскими интерфейсами, и работал над заменой большого количества пользовательского интерфейса на один проект, который в своем первоначальном воплощении имел аналогичный подход (все приложение было деревом объектов, доступным через контекстные меню и листы свойств), это был NetBeans 2.0 около 1998 года - IDE в качестве гигантский иерархический JavaBean).

Суть в том, что ваши пользователи не заботятся о вашей архитектуре, они заботятся о том, чтобы сделать то, что им нужно сделать, в наиболее приемлемом для всех простых смертных наборах взаимодействий, которые вы можете придумать. Если это произойдет, чтобы выровняться с вашей архитектурой, у вас будет счастливый день, но это действительно бесшумность. Попытка заставить пользователей заботиться (или даже знать) о вашей архитектуре - это рецепт для программного обеспечения, которое никто не хочет использовать.

Код обычно должен быть спроектирован вокруг двух не всегда совместимых целей:

• Поддержание работоспособности - люди, которые не пишут код, могут понять код
• Стабильность и производительность - то есть действия, которые компьютер запрашивает у компьютера физически, возможны и могут быть выполнены в течение разумного периода времени.

Абстракции и структуры кода, которые имеет смысл создавать для достижения этих двух целей, очень редко отображают именно элементы пользовательского интерфейса любого типа. Иногда вам это удается - едва ли ваша аудитория техническая. Но даже там, скорее всего, вам понравится больше пользователей с хотя бы слоем адаптера уровня презентации поверх архитектуры, что имеет смысл для программистов и машин.