WPFのDataTemplateに見るXAMLの特徴

コンピュータ

WPFを触っていると、XAMLという言語の独特さを感じる場面がいくつかあります。
その中でも典型的な部分は、ListViewとDataTemplateの関係です。

一見すると、XAMLで書かれたUIは不自然に見えます。
特に、HTML × JavaScript に慣れていると、違和感はより強くなります。

この記事では、ListViewのDataTemplateを題材にしながら、
XAMLがなぜこの形になったのか を整理してみます。

ListViewItemを自分で作っていない

WPFのListViewでは、通常 ListViewItem を直接XAMLに書きません。

<ListView ItemsSource="{Binding Items}">
    <ListView.ItemTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding Name}" />
        </DataTemplate>
    </ListView.ItemTemplate>
</ListView>

ここで記述しているのは、ListViewItemそのものではなく、
「データ1件分の見た目」 だけです。

ListViewItemの生成や管理は、すべてWPFの内部で行われます。
開発者は、それを意識する必要がありません。

HTML × JavaScript との違い

HTML × JavaScript で同じことを行う場合、
JavaScriptでDOMを動的に生成するのが一般的です。

  • 配列をループする

  • 要素を生成する

  • 親要素に追加する

UIは「コードで動的に作るもの」という感覚が自然です。

それに対してXAMLでは、

  • ループを書かない

  • 生成処理を書かない

  • DOM相当の操作もしない

ただ「こう表示する」という構造を宣言するだけです。

この違いは、かなり極端に見えます。

なぜXAMLはこうなったのか

この設計の理由は単純です。
WPFはデータバインドを中心に設計されているからです。

WPFでは、

  • UIはデータの表示結果である

  • データが変わればUIも変わる

という考え方が前提になっています。

そのため、

  • UIをどう作るか
    よりも

  • データとUIがどう対応するか

を記述する方が重要になります。

処理ではなく、対応関係を書く

HTML × JavaScript は命令型です。

  • 何を

  • どの順番で

  • どう操作するか

という「処理の流れ」をコードで書きます。

一方、XAMLは処理を書きません。

XAMLが書くのは、

  • この型のデータは

  • この構造で

  • このプロパティに表示される

という 対応関係 だけです。

DataTemplateは、その対応関係を定義する仕組みです。

動的に見えるが、動的に書いていない

XAMLで書かれたUIは、見た目としては完全に動的です。

  • データ件数が変わる

  • 内容が更新される

  • 表示が自動的に切り替わる

それでも、開発者は動的な生成処理を書いていません。

ListViewItemの生成、破棄、再利用、仮想化といった処理は、
すべてフレームワーク側が引き受けています。

これは、

UI操作の責任を、フレームワークに寄せる

という設計判断の結果です。

不自然さの正体

XAMLが不自然に見える理由は難しくありません。

  • 従来のUIは「画面を操作する」発想だった

  • XAMLは「データを表示する」発想だから

視点が UI中心 から データ中心 に反転しています。

HTML × JavaScript の方が自然に見えるのは、
単にこちらの歴史が長いからです。

DataTemplateが象徴しているもの

DataTemplateは、

  • ListViewItemを直接書かせない

  • UI生成処理を書かせない

  • データと見た目の対応だけを書かせる

という点で、XAMLの思想を非常によく表しています。

HTML × JavaScript ならコードで動的に書く部分を、
XAMLでは宣言として表現している。

これが、DataTemplateに見るXAMLの最大の特徴です。

まとめ

XAMLがこの形になったのは、奇抜さや流行の結果ではありません。

  • データバインドを主役に据えた結果

  • UI生成を処理ではなく宣言で表現するため

  • データとUIの責務を分離するため

その結果として、

HTML × JavaScript であれば処理で書くUI生成を、
XAMLでは宣言として記述する

という設計になりました。

XAMLの分かりにくさは欠点でもありますが、
データバインドを前提にすると必然の形 だったとも言えます。

スポンサーリンク

コメント