データとUIコントロールを結び付けるコーディングは面倒？
アプリケーション開発で面倒なのは、データとUIコントロールの連携です。画面に表示される入力ボックスにデータを表示して、編集結果を反映させるというアレです。
コンポーネントベースの開発環境であれば、データベースアクセスをカプセル化して、あまりコードを書くことなく、UIを作成できます。しかし、扱うデータがコンポーネントによってサポートされていないものだったりすると、途端にスクラッチのコーディングに戻ってしまうなど、何かと不便です。
特に最近では、Webサービス経由でデータを扱ったり、多層化してクライアント側で直接データベースのデータを扱わなかったりするような形態が増えてきており、上記のやり方が通用しなくなってきています。
Delphi / C++Builderを例に見てみましょう。
データとUIコントールの連携 - Delphiの場合
Delphiはもともと、Oracle向けのクライアントアプリケーション開発ツールを想定して開発された経緯があることから（DelphiというギリシャっぽいネーミングもOracle由来でしょう）、データベースとの連携は最初から組み込まれていました。データベースアクセスコンポーネントとデータベース対応のUIコントロールを結び付けて、データを表示、編集できます。ほぼノンコーディングです。
現在では、対応データベースも幅広く、Oracle、MS SQL Server、DB2、Informix、Sybase、SQL Anywhere、InterBase、MySQL、SQLite、ODBCなど。Azureにもつながります。
近年のアプリケーション形態で起きるデータ連携の問題
ここで2つの問題があります。古典的なクライアントサーバーアプリでは、クライアントは直接データベースに接続していました。デスクトップデータベースの延長のような感覚です。Excelの表のようなグリッドでデータを表示するアプリケーションがその典型です。
ところが、近年では、データ量が増加していることと、クライアントサーバー以外、Webやモバイルなどからもデータにアクセスしたいという要求があがっていることなどから、単純な2層では収まらなくなってくるケースが増えています。そうすると、これまでのデータアクセスコンポーネントが、そのまま使えなくなります。クライアントに持ってくるデータ量も最適化しなければならなくなります。
そうすると、中間層では引き続きコンポーネントを使って効率化したとしても、クライアント層でUIとデータを結び付けるコーディングが増加してしまいます。ロジックまわりでなく、UIまわりの制御に膨大なコードを書くとなると、生産性低下に直結してしまいます。
もうひとつは、UIコントロールです。最近のアプリケーションは、見た目にも美しくなってきました。データもさまざまな形態で表示できるようになっています。ところが、これらがデータベース対応のコンポーネントでないと、データをUIコントロールに表示するために、またたくさんコードを書かなければならなくなります。
