Будущее Явного шаблона Объектов (и автоматическая генерация UI) [закрытый]

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

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

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

Смотрите на JMatter, который является скорее лучше выглядящей реализацией Явных Объектов.

http://www.jmatter.org

существует также работа Chris Muller над МАУИ и работа Lukas Renggli над Magritte (оба Писка/Smalltalk)

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

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

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

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

Разработчик Oracle’s 2000, например, был на правильном пути во включении не только объекты и отношения в модели, но также и задачи в форме функциональной иерархии. Затем они унесли его путем неправильного употребления этих метаданных (например, предполагая, что глубина всегда предпочитается ширине) и включая фундаментальные дефекты при генерации UI (например, только одно главное окно может быть открыто за один раз). Результатом был IUS, которые даже не согласовывались с собственными Стандартами Пользовательского интерфейса Приложений Oracle’s.

Ре: qn № 1... Вы верите в понятие автоматической генерации UI от метаданных?... Я определенно собираюсь ответить на 'да' на Ваш первый вопрос, будучи одним из разработчиков к Явным Объектам (Java) платформа и запись книги по DDD + НЕТ.

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

Относительно qn № 2..., к каким проблемам можно приблизиться этот путь..., мы всегда говорили, что НЕ более подходит для "суверенных приложений" (транзакционные, операционные системные, используемые внутренне в организации) к "переходным приложениям" (как киоск аэропорта, скажите). НИКАКОЙ GUI действительно не требует, чтобы пользователь был знаком с доменом, иначе они не будут знать то, на что они смотрят.

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

другая вещь добавить к этому, хотя то, что НИКАКОЙ подход не имеет значение (я верю), даже если Вы принимаете решение записать пользовательский GUI и/или уровень представления. Таким образом, можно использовать его в качестве средства проектирования для создания очень твердого pojo доменного слоя и затем очистить его, как Вы будете. Проблема состоит в том, который НЕ первоначально никогда не продавался в тех терминах, так же большинство не будет видеть шаблон как бескомпромиссное дело.

Dan

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

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

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

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

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

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

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

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

1. Удобство сопровождения — люди, которые не писали код, могут его понять
2. Стабильность и производительность — т. е. действия, которые код запрашивает у компьютера. физически сделать это возможно и может быть выполнено в разумные сроки

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