Каковы реальные преимущества языков декларативного UI, такие как XAML и QML?
Я в настоящее время оцениваю QtQuick (спокойный Набор Создания пользовательского интерфейса), который будет выпущен как часть Qt 4.7. QML является основанным на JavaScript декларативным языком позади QtQuick.
Это, кажется, очень мощное понятие, но я задаюсь вопросом, может ли кто-либо, это сделало широкое применение из другого, более сформировавшихся языков декларативного UI как XAML в WPF или Silverlight, дать понимание реальной выгоды, которая может быть получена от этого стиля программирования. Различные преимущества часто цитируются:
- Скорость разработки
- Разделение сил между презентацией и логикой
- Лучшая интеграция между кодерами и разработчиками
- Изменения UI не требуют перекомпиляции
Кроме того, есть ли какие-либо оборотные стороны? Несколько потенциальных проблемных областей приходят на ум:
- Скорость выполнения
- Использование памяти
- Добавленная сложность
Есть ли какие-либо другие соображения, которые должны быть приняты во внимание?
3 ответа
(Обновлено)
Ошибочное представление о XAML состоит в том, что он не компилируется. Он действительно скомпилирован до BAML - двоичного предварительно токенизированного XAML. По-видимому, была также скомпилированная версия XAML, называемая CAML. OP указал мне на эту хорошую статью , объясняющую, что такое XAML / BAML и CAML.
В любом случае, на вопрос, зачем его использовать:
XAML - это просто формат сериализации для объектов C #, который особенно хорошо подходит для описания иерархических структур объектов, как в графических интерфейсах WPF.
WPF помогает вам писать менее скучный код на C # вроде этого:
var grid = new Grid();
grid.Content.add(new TextBlock() {Text = "Hello"});
grid.Content.add(new TextBlock() {Text = "World"});
и просто выражать его более читаемым образом, например:
<Grid>
<TextBlock Text="Hello">
<TextBlock Text="World">
</Grid>
Поскольку вложение объектов WPF (размещение содержимого внутри других объектов) может стать очень глубоким , WPF делает его намного проще для чтения, чем полученный код C #.
Что касается разделения задач: XAML здесь тоже помогает, поскольку он позволяет только выражать объекты и их отношения / свойства, а не логику. Это заставляет вас отделить логику от макета пользовательского интерфейса. Шаблон MVVM очень хорошо подходит для этой задачи и обеспечивает возможность тестирования и взаимозаменяемые представления.
Дополнительную сложность в XAML также можно легко игнорировать, потому что тот же код в C # становится более сложным, чем разметка XAML.
Я не могу дать вам никакого представления о QTQuick. Извините
Смысл декларативного кодирования, то есть WPF или QTQuick, заключается в предоставлении разделение между разработчиком и, предположительно, художником, реализующим визуальные аспекты вашего приложения. Что касается WPF, я считаю, что отладка становится немного сложнее. Пока мы говорим, я компилирую последнюю версию QT, чтобы посмотреть на QTQuick. (Это занимает много времени, и у меня есть время посмотреть на stackoverflow :-)) Так что у меня пока нет мнения по этому поводу.
QtQuick расширяется с помощью подключаемых модулей C ++, на самом деле ребята из Qt рекомендуют вам делать UI, анимацию, переходы и т.д. в QtQuick / QML, в то время как вся ваша бизнес-логика находится на C ++ / Qt. Таким образом, вы получаете лучшее из обоих миров, вы можете отлаживать свой код C ++, как обычно, и в то же время создание пользовательского интерфейса становится простым и чрезвычайно простым.
Еще одна важная мысль о QtQuick / XAML заключается в том, что они имеют аппаратное ускорение, поэтому, например, вы можете получить довольно хороший fps без каких-либо усилий. Так что они совсем не медлят в том, что намеревались достичь.
Это экономит время, очень много времени. Я сделал UI с кодом за 3 дня, сделал то же самое в QML за 2 часа.