Java, построитель GUI или ручное кодирование?

Ответ 1

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

Я не знаю, ссылаетесь ли вы на веб-приложения или настольные приложения, но в целом я не нашел Java Gui builder, который производит элегантный вывод. Netbeans Swing сгенерированный код, например, беспорядок. Возможно, если бы был хороший строитель, я бы передумал. У меня не возникло проблем с использованием конструктора форм Visual Studio - он создает хороший код, который вы можете читать и понимать.

Для настольных приложений смотрите MiGLayout. Это менеджер компоновки, а не строитель, для Swing и SWT, которые облегчат вашу жизнь.

Ответ 2

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

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

В соответствии с "нечитаемым" вы должны рассмотреть возможность использования лучшего генератора графического интерфейса. Я слышал только положительные вещи о NetBeans, и я использовал конструктор GUI IntelliJ, код которого довольно чистый.

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

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

Ответ 3

Это мой опыт:

Мне никогда не нравился код, созданный создателем GUI. По крайней мере, в мире VB это не так, что все (ну, почти) будут использовать одну и ту же среду IDE для создания приложений. В Java люди используют несколько IDE, а некоторые используют VIM и Notepad. И все IDE не генерируют такой же код. И еще одна проблема заключается в том, что они обычно не понимают код, созданный другими IDE. Поэтому, чтобы ответить на ваш 1-й вопрос, я не рекомендую.

Следующий вопрос: какой строитель лучше? В прошлый раз, когда я использовал, Netbeans был лучше, чем большинство из них, которые я пробовал.

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

Дайте нам знать ваше решение!

Ответ 4

Я использую NetBeans Java Swing GUI Builder (Matisse) для всех моих проектов за последние 3 1/2 года. Я читал так много жалоб людей на GUI Builders, и самые опытные программисты приветствуют всех, кто даже намекает на использование одного, но вот мой опыт:

• Не редактируемый код никогда не требуется для редактирования. Действительно, GUI Builder предоставляет скелет для вашего графического интерфейса. Вы перетаскиваете, уменьшаете, изменяете размер и ограничиваете свои компоненты с помощью редактора, но контент таблицы, список для поля со списком и т.д. Все нужно обрабатывать на бэкэнд. Создатель GUI позволяет вам сосредоточиться на этом, пока он заботится о том, чтобы все выглядело красиво и оставалось на месте.
• WYSIWYG всегда более продуктивен. Текстовые процессоры являются свидетельством этого. Люди скажут вам: "вы не редактируете код GUI, поэтому, если это экономит ваше время, это не так много времени". Но это утверждение чрезвычайно относительное. Когда вы работаете в программной среде с моделью процесса, которая требует постоянных обновлений из-за изменений бизнес-модели, это утверждение ложно. Кроме того, вы тратите большую часть своего времени на контент своего английского эссе, не так ли? Таким образом, этот аргумент сказал бы, что WYSIWYG Word-процессоры не экономят вас столько времени, и такое утверждение будет падать на глухие уши, потому что никто не захочет скомпоновать их внешний вид эссе.
• Ничего не может сделать GUI Builder, который может сделать этот рукописный код, в то время как я потратил часы, пытаясь решить небольшие проблемы с рукописным графическим интерфейсом, который занял у меня 1 минуту в построителе графического интерфейса.

Создатель GUI Netbeans, в частности, стал намного лучше с течением времени, что большая часть полученного им flak (похожего на большую часть flak Java получила) была действительно аннулирована. Это отличная программа, и это отличный способ быстро и эффективно создавать многофункциональные, красивые интерфейсы. Я очень рекомендую хороший GUI Builder, особенно Netbeans.

Там я это сказал.

Нет, я не работаю для них.

Ответ 5

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

Ответ 6

Если у вас слишком сложные формы для сборки, вы можете взглянуть на DesignGridLayout, это Swing LayoutManager с что позволяет легко писать код для вашей формы и легко читать этот код (и поддерживать, я имею в виду, изменять, если необходимо) и визуализировать форму через код.

С DesignGridLayout одна строка компонентов в вашей форме - это одна строка кода. Нет XML, полная безопасность во время компиляции. Нет жестко заданных значений интервала, выравнивания... DesignGridLayout обрабатывает все это для вас.

Краткая кривая обучения и как быстрая компоновка формы в качестве дизайнера GUI!

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

Ответ 7

Мы делаем это вручную, но с библиотекой, помогающей нам с макетом (JGoodies Forms) и так далее. Далее мы используем набор предопределенных компонентов, которые мы подключаем к нашему пользовательскому интерфейсу (Jide). Хорошо работает для нас.

Ответ 8

Я использовал много дизайнеров GUI на протяжении многих лет (для разных языков): Delphi, Visual Studio, JBuilder, Netbeans.

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

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

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

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

Ответ 9

Для систем с множеством простых форм я склоняюсь к XML-маршруту -

• определить файлы XML для информации и любой рабочий поток для каждой формы
• создать XSLT для создания Java/XHTML/любого кода для запуска форм на настольном ПК/мобильном/веб-сервере
• также создают XSLT для генерации объектов данных исходного кода и т.д.

Вы можете использовать XForms и их реализации, но обычно я работаю в тех местах, где покупка решений занимает больше времени, чем создание собственного простого XSLT. Обычно требуется неделя, чтобы получить все и запустить, если в формах не слишком много специализированных виджетов. Если вы создаете собственные генераторы кода, у вас есть полный контроль. Если вы обнаружите, что хотите переключать все свои формы на прокрутку вверх/вниз, чтобы быть представленными в столбцах, то есть только одно место, которое вам нужно изменить, а не изменять реализацию каждой формы. (хотя вы могли бы создать структуру для абстрактной информации формы из презентации на Java, она не очень подходит для такого декларативного программирования)

Ответ 10

Я лично поклонник ветки графического интерфейса от кода (в противном случае вы в конечном итоге с проблемами, о которых вы только что упоминали). Также, похоже, эта тенденция: у Microsoft есть свой XAML, вы продолжаете слышать о разных механизмах просмотра для MVC и т.д.

Почему бы не пойти с графическим интерфейсом на основе XML? Вы можете попробовать что-то вроде JFormDesigner, которое может обрабатывать как XML, так и сгенерированные кодом макеты.

Ответ 11

Я делал это в последнее время - я использую Netbeans и изначально был разочарован отсутствием контроля сгенерированного кода. Затем я обнаружил, что вы можете добавить пользовательский код из построителя GUI, который преодолел большинство проблем. Однако я больше расстроился менеджером компоновки в NetBeans и обнаружил, что это ухудшает мою производительность больше, чем что-либо. Я переключился на MiGLayout и теперь большую часть кодирования выполняет вручную. Сказав это, NetBeans в целом довольно хорош, и, возможно, мне следовало потратить больше времени на изучение GroupLayout.

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

Ответ 12

Я использовал Netbeans в прошлом для создания кода GUI и использовал Eclipse для написания логики программы. Просто включите GUI-код в отдельную исходную папку LINKED.

Ответ 13

Я бы сказал, что используйте только GUI-конструктор, если вы понимаете, что вы пытаетесь сделать, чтобы вы могли сделать это сами.

Ответ 14

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

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

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

Ответ 15

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

У нас около 100 из этих beans, которые мы использовали в более чем 600 формах. Ниже приведена картинка с изображением одного из этих beans:

Эта панель состоит из стандартного ярлыка, обязательного индикатора (красная звездочка), поля редактора (в данном случае комбинированного поля) и поля только для отображения (серый квадрат). В этом случае поля combo-box и display-only являются взаимоисключающими - только один из них видим за раз, в зависимости от того, в каком режиме находится форма/поле.

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

Теперь, как мы строим наши формы? Ну, мы делаем все наши формы в построителе GUI NetBeans Matisse. Мы очень этому довольны. Хотя вы не можете редактировать код, который он генерирует, у меня никогда не было таких случаев, когда это мешало мне что-то делать в графическом интерфейсе. beans, о котором я упоминал выше, можно легко добавить в палитру, поэтому добавление их в формы - это drag-n-drop.

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

И это тоже легко, а это значит, что мы можем заставить некоторых (не программистов) бизнес-аналитиков создавать формы до того, как программист добавит код "под капот".

Ответ 16

Я начал программировать на VB, а затем перешел к С#. Я бы сказал, что разработчик GUI Netbean по-прежнему далеко от Microsoft, особенно с менеджером макета в форме. Это очень радует, когда вы пытались переместить кнопки и ярлык, чтобы их выровнять по желанию, и те, которые вы не хотите переместить, начали перемещаться по всему месту.

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