概要
あなたが管理している気象アプリは、最近閉鎖が発表された気象サービスを使っています。 そこで、他の気象サービスの調査に取りかかる必要が出てきました。 サービスを変更すると、データが変更される可能性があることを認識し、分離コードの使用からデータ バインディングを使用して UI を更新する方法に切り替えたいと考えていました。 この方法なら、どの気象サービスを使うかを決めるときに、UI への影響を心配する必要がなくなります。
演習で行ったデータ バインディングにより、データの変更時に UI を更新するために必要なコードが減りました。 ボタンのイベント ハンドラーを使って UI 上のコントロールとやり取りしてデータを表示するのではなく、データ バインディングに移行しました。 気象サービスのデータ オブジェクトはページのバインド コンテキストとして設定され、ページ上のコントロールはそのデータ オブジェクトのプロパティにバインドされました。 気象サービスがどのように更新されたかに関係なく、UI はデータと自動的に同期されました。
データ バインディングなしでコードビハインドが影響を受けることを想像してみてください。 コントロールの名前を変更したり、1 つのコントロールを別の種類に変更したり、コントロールを削除したりすると、コードビハインドでコンパイルできなくなります。 気象サービスが特定フィールドのデータ (湿度など) の提供を停止した場合、それを UI に表示しようとすると、コードはクラッシュします。 ユーザーはアプリが突然動作を停止し、何が起こっているのか分からなくなります。
データ バインディングの場合、データは UI と自動的に同期されます。 気象データが変更されるとすぐに、それにバインドされているものも変更されます。 UI プロパティ型とデータ オブジェクト型が一致しない場合、コンバーターはバインドされたデータを変換して、UI によって正しく表示されるようにします。 これにより、UI を維持するために必要なコードビハインドを減らすことができます。 データがどこから来て、どのようにトリガーされたかは、ほとんどの UI にとって問題になりません。 データ オブジェクトで湿度が提供されなくなった場合、データがバインドされた UI はクラッシュするのではなく、湿度ラベルに何も表示されなくなります。 ユーザーにとって、アプリがクラッシュするよりも、はるかに優れたエクスペリエンスです。