Jakie są rzeczywiste zalety języków deklaratywnych, takich jak XAML i QML?

Question

Obecnie analizuję QtQuick (Qt User Interface Creation Kit), który zostanie wydany jako część Qt 4.7. QML jest językiem deklaratywnym opartym na języku JavaScript za QtQuick.

Wydaje się być bardzo silny pojęcie, ale zastanawiam się, czy ktoś to robił szerokie zastosowanie innych, bardziej dojrzałych języki deklaratywne-UI jak XAML w WPF lub Silverlight może dać żadnego wglądu w korzyściach rzeczywistych że można uzyskać z tego stylu programowania. Różne zalety są często cytowane:

• Szybkość rozwoju
• Siły oddzielenie prezentacji i logiki
• Lepsza integracja między programistów i projektantów
• zmiany UI nie wymagają ponownej kompilacji

Czy są jakieś wady? Kilka potencjalnych obszarów zainteresowania wiosny do umysłu:

• szybkość realizacji
• Użycie pamięci
• Dodano złożoność

Czy są jakieś inne względy, które powinny być brane pod uwagę?

Answer 1

(Aktualizacja)

Błędne z XAML jest to, że nie jest skompilowany. W rzeczywistości jest on skompilowany do BAML-a binarnie z pre tokenem XAML. Najwyraźniej istniała wersja XAML skompilowana przez IL, zwana także CAML. OP wskazał mi na to, good article wyjaśniając czym są XAML/BAML i CAML.

W każdym razie, na pytanie dlaczego z niego korzystać:

XAML jest po prostu format serializacji dla C# obiektów, które jest szczególnie dobrze nadaje się do opisania hierarchicznych struktur obiektowych, jak znaleźć w WPF GUI.

Co WPF pozwala zrobić, to napisać mniej nudny kod C# tak:

var grid = new Grid(); 
grid.Content.add(new TextBlock() {Text = "Hello"}); 
grid.Content.add(new TextBlock() {Text = "World"}); 

i po prostu wyrazić w bardziej czytelny sposób jak ten:

<Grid> 
    <TextBlock Text="Hello"> 
    <TextBlock Text="World"> 
</Grid> 

Ponieważ WPF obiektowo gniazdowania (oddanie rzeczy wewnątrz innych obiektów) może być bardzo głęboka, WPF znacznie ułatwia czytanie niż wynikowy kod C#.

Jeśli chodzi o oddzielenie obaw: XAML pomaga również tutaj, ponieważ pozwala tylko wyrazić obiekty i ich relacje/właściwości, a nie logikę. To zmusza do oddzielenia logiki od układu interfejsu użytkownika. Wzorzec MVVM bardzo dobrze nadaje się do tego zadania i umożliwia testowalność ewaluacyjną oraz wymienne widoki.

Dodatkową złożoność w XAML można również łatwo usunąć, ponieważ ten sam kod w języku C# jest łatwiejszy w użyciu niż znaczniki XAML.

Nie mogę jednak podać żadnego wglądu w QTQuick. Przepraszam

Answer 2

Punktem kodowania deklaratywnego, tj. WPF lub QTQuick, jest zapewnienie separacji między programistą i prawdopodobnie artystą wdrażającym wizualne aspekty aplikacji. Jeśli chodzi o WPF, uważam, że debugowanie staje się nieco trudniejsze. Kiedy mówimy, kompiluję najnowszą QT, by spojrzeć na QTQuick. (To zajmuje dużo czasu i mam czas, aby spojrzeć na stackoverflow :-)) Więc nie mam jeszcze na ten temat opinii.

Answer 3

QtQuick jest rozszerzalny przez wtyczki C++, w rzeczywistości to, co poleca Qt guys, to że robisz interfejs użytkownika, animacje, przejścia itp. W QtQuick/QML, podczas gdy cała twoja logika biznesowa jest w C++/Qt. W ten sposób uzyskasz to, co najlepsze z obu światów, możesz debugować swój kod w C++, tak jak zwykle, a jednocześnie tworzyć interfejsy użytkownika bez wysiłku i niezwykle łatwe.

Kolejną ważną myślą o QtQuick/XAML jest to, że są przyspieszane sprzętowo, więc na przykład można uzyskać całkiem niezły obraz bez żadnego wysiłku. Nie są więc powolne w tym, co zamierzali osiągnąć.

Oszczędza czas, dużo czasu. Zrobiłem UI z kodem w 3 dni, zrobił to samo w QML w 2 godziny.

Answer 4

QML/XAML są:

• Doskonały do ​​wzorca MVVM
• Hardware przyspieszone (QML z użyciem OpenGL dla Windows, Mac, Linux i telefonów poniekąd ... XAML z użyciem DirectX dla Windows i jego telefon wersja)
• Bliżej artystów
• można tworzyć wielkie i ładne UI przy użyciu XAML/QML
realizacja
• Łatwiejszy UI
• Nicea animacja jest możliwe
• W XAML, zwykle można utworzyć Silverlight wersję aplikacji tylko z trochę zmian
• W XAML istnieje kilka świetnych funkcji, takich jak szablon, Trigger (DataTrigger, spust, EventTrigger) Binding (po dowolnej stronie, a także po obu stronach), Zasoby, Polecenia, Właściwość Dependency i Właściwości podlegające obowiązkowi zgłoszenia.

Ale proszę pamiętać w XAML: (jestem programistą XAML, więc nie mam punktów QML)

• XAML debugowania nie jest możliwe
• W przypadku każdej zmiany w XAML, cały program musi Ponowna kompilacja:

• Zachowaj ostrożność w działaniu. Na przykład, jeśli użyjesz wielu RoutedCommands w XAML, twoja aplikacja będzie bezużyteczna!

• W XAML niektóre funkcje nie działają zgodnie z oczekiwaniami. Istnieje niestety kilka sztuczek. (Powinno być jasne ... powinien działać zgodnie z oczekiwaniami ... czy nie?)

• Należy zachować ostrożność w przypadku niektórych podobnych przestrzeni nazw, takich jak BitmapEffect i Effect. Istnieją różne funkcje i koszty. (np. BitmapEffect ma pewne efekty z renderowaniem oprogramowania, a efekt ma pewien efekt z renderowaniem sprzętowym)

• W świecie rzeczywistym artyści nie mogli używać WPF jako Flash (przynajmniej z dobrą wydajnością).

• Niektóre funkcje działają w specjalnych miejscach. Na przykład DataTrigger działa tylko w tagu Style, a nie w sekcji zasobów.

• Istnieje kilka słabych punktów w XAML. Kilka przykładów: nie ma żadnej sekwencyjnej animacji ... nie możesz wykonać żadnych obliczeń w XAML (musisz napisać konwerter w języku C# nawet dla liiiittle pracy! JavaSript jest świetnym zamiennikiem w QML) ... niektóre atrybuty są duplikowane. na przykład x: Nazwa i nazwa ... Kontrolowanie Widok z ViewModel nie jest jasny. na przykład zamykanie Widok z ViewModel (potrzebujesz kodu CodeBehind)

• Toooooo wiele błędów czasu wykonania. Jeśli użyjesz tagów w złym miejscu, zauważysz błąd składniowy, ale wiele błędów pojawi się właśnie w czasie wykonywania. na przykład jeśli wybieram właściwość tła (zamiast Background.Color) dla ColorAnimation, zostanie skompilowana pomyślnie, ale w uruchomionej animacji ... BUMP ... błąd runtime !!! w takim przypadku na Expression Blend, aplikacja zawiedzie !!!