Пользовательский интерфейс: альтернативы и будущее

UI. Сопоставление информации о передаче информации/данных из уровня biz-layer/datamodel приложения в пользовательский интерфейс и из пользовательского интерфейса обратно в datamodel, швы должны быть немного проигнорированы разработчиками языка и каркаса.

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

Я имею в виду Эрика Мейера, Андерса Хейлсберга и их команд, т.е. приложили огромные усилия для устранения несоответствия импеданса между БД, XML и кодом... но в большинстве своем оставил UI. (ну да .net имеет привязку данных, но попытайтесь ее использовать, а затем поговорите о реальном решении) Дело в том, что рационально, если не обрабатывать привязку данных специально как первоклассную особенность языка f.e? Почему в наших инструментах сегодня есть только ограниченная (или нет) поддержка шаблонов MVC/MVP?

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

Ответ 1

Связывание WPF, хотя и является хорошим, слишком сложное, оно сочетает в себе функции XPath с обычным привязкой .Net и является супер гибким, но очень сложным для отладки, когда оно становится сложным, а также очень долговечным - сколько IValueConverter делает один кусок кода нужно?

DependencyObject из WPF является блестящим, хотя - свойство, которое управляет памятью разумно, построило уведомление об изменениях - это хороший старт для привязки и свойств в целом.

Ответ 2

Связывание данных в Cocoa и Objective-C очень живое и здоровое. Частично это связано с тем, что оно построено на основе кодирования ключевых значений и наблюдения ключевых значений, которые являются очень прочными и хорошо продуманными функциями в Cocoa. Он также хорошо интегрирован во множество новых технологий, которые Apple разрабатывает, таких как Core Data.

Ответ 3

Другими структурами, поддерживающими привязку данных, являются Adobe Flex и Microsoft WPF.

Ответ 4

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

Вы можете указать DataTemplates, которые управляют отображением определенного типа. Вы можете определить триггеры, которые позволяют изменять пользовательский интерфейс на основе изменений связанных объектов (или в другом месте пользовательского интерфейса). Короче говоря, вы действительно должны смотреть на WPF, если вы чувствуете, что состояние представления пользовательского интерфейса/привязки отсутствует.

Вот недавний post, который иллюстрирует мощь WPF, где с помощью базовых конструкций вы можете отображать карту с координатами на ней.

Ответ 5

В Python для этого можно использовать Enthought Traits. Вы определяете модель, и эта модель уже содержит все знания и логику, чтобы вы могли создать для нее редактор с помощью одной строки кода.

Ответ 6

Я нахожусь на поздних этапах проекта портирования, используя код, созданный AppMaker, из графического интерфейса Macintosh на основе C в WPF.

Стиль генерации кода AppMaker намного опередил свое время - 15 лет назад он сгенерировал модельный код с привязкой данных и подход, основанный на свойствах. Недостатком кода C является то, что все сантехника была обнаружена.

Этот проект был увлекательным - с архитектурой с чистой привязкой и структурой команд (хотя и уродливым кодом) в WPF. Я фактически написал новый генератор кода AppMaker для экспорта исходной объектной модели в XML и работал с ней с Ruby для генерации XAML, С# и С++/CLI с тех пор.

Я очень впечатлен тем, насколько хорошо работает модель привязки данных в WPF, хотя найти сладость того, что добавить в XAML vs С#, интересно. Как пояснялось в презентации недавней презентации DevJam, мы решили использовать трехслойный подход

очень худой XAML для стилизации,
С# для привязки,
С++/CLI для реализации ViewModel.

Я являюсь фанатом связывания с обратной стороны - моя платформа С++ OOFILE сначала использовала метод привязки для упрощения базы данных подключения к формам в разных Графические интерфейсы GUI около 1997 года.

Как интересный момент, я приобрел AppMaker у первоначального владельца в США, после нескольких лет совместной работы, где я написал генераторы кодов Windows. Кажется почти невероятным, что небольшая компания в Перте, Западная Австралия, со сложным графическим интерфейсом AppMaker для порта, должна найти оставшегося эксперта AppMaker в мире, который живет примерно в 30 милях отсюда.

Ответ 7

SWT/JFace, слой пользовательского интерфейса Eclipse, недавно был расширен с возможностями привязки данных UI. См. http://wiki.eclipse.org/index.php/JFace_Data_Binding