Является ли привязка данных пользовательского интерфейса в Java большей проблемой, чем того стоит?

Недавно я потратил некоторое время на изучение и попытку использования различных инструментов привязки данных Java, таких как JGoodies, GlazedLists, JSR-295 и т.д. Проблемы, которые я пытался решить, не так уж трудны, однако количество кода, которое мне пришлось написать в поддержку процесса привязки, сильно перевешивает любые упрощения, которые он предоставляет.

Я обнаружил, что предоставленные инструменты не поддаются ни на что иное, кроме тривиальной композиции и расширения (GlazedLists, в частности, предоставляет большой набор инструментов, но слишком сложна для расширения системы).

Мне очень нравится идея привязки данных, однако она кажется глубоко ошибочной, поскольку она стоит. Я что-то пропустил?

Ответ 1

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

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

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

Ответ 2

Если ваше приложение тривиально, вам действительно не важно, если вы выполняете привязку, или если вы пишете своих слушателей один за другим.

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

Если вы правильно используете привязку, вы можете полностью разделить поведение gui и gui. Это, в свою очередь, означает

вы можете протестировать модель презентации (материал, к которому вы привязываете свои компоненты) без качания без EDT, просто с обычными модульными тестами.
вы можете проверить привязку с простым тестом, в котором задействовано только очень мало компонентов Swing.

Если вы попытаетесь достичь того же без привязки, вы в конечном итоге напишите свою собственную структуру привязки.

Существует серьезная проблема, хотя ИМХО о привязке в мире Java. Это заставляет вас писать getters + setter с PropertyChangeSupport, который является утомительным и подверженным ошибкам. Я не вижу реалистичного способа исправить это на Java, но другие языки (думаю, Scala) предлагают интересные возможности здесь. Посмотрите мой последний пост в блоге, если вы заинтересованы: http://blog.schauderhaft.de/2011/05/01/binding-scala-objects-to-swing-components/

Ответ 3

http://msdn.microsoft.com/en-us/library/3z66c30h(v=vs.80).aspx

Это печальная история инженеров Sun Java, создающих красивые спецификации, которые не могут поддерживаться в открытом пространстве инструментов Java (например, IBM, WebLogic и др.).

Учитывая, что MS контролирует язык и пространство инструмента для своих продуктов, никто в MS-land не задает вопросов о том, "зачем нам нужны спецификации привязки данных?".

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

Очевидно, что если вы делаете все это вручную, это "плита котла" и "подробный". Но если вы перетаскиваете коннектор из своего источника данных в таблицу пользовательского интерфейса, и он просто работал (например, магия), вы не задавали бы такие вопросы. Жаль. (Теперь спросите себя, почему IBM назвала их IDE "eclipse"..)