DataSource for Entity Framework for WinForms
非 GUI コードでライブビューを使用する方法
C1LiveLinq > LiveLinq の使用方法 > 非 GUI コードでライブビューを使用する方法

ライブビューの使用は、GUI に限定されません。より一般的には、ライブビューにより、ビュー指向プログラミングとも呼ばれる宣言型プログラミングが可能になります。また、非 GUI のバッチ処理コードも、ライブビューを使用して宣言型にすることができます。

一般に、すべてのアプリケーションは何らかのデータに作用し、どのデータも、ベースデータまたは派生データのいずれかと解釈することができます。ベースデータには、アプリケーションが扱う Customers、Orders、Employees などのメインオブジェクトがあります。これらのオブジェクト(特定クラスのすべてのオブジェクトを含むコレクション。クラスの "エクステント" とも呼ばれる)は、ベースデータに何か変更を行う必要がある場合に、アプリケーションによって修正されるオブジェクトです。ただし、アプリケーションがこのベースデータに直接作用したり、クラスのエクステント全体に直接作用することはほとんどありません。通常、アプリケーションは、エクステントのフィルタ処理と形成を行い、エクステントどうしを組み合わせて、特定の操作に必要なデータのスライスを取得します。このデータの形成/フィルタ処理/結合/スライスが、派生データ(基底のベースデータではなく)を取得するプロセスです。LINQ が世に出る前は、純粋な手続き型コードとそれに伴うすべての複雑な機構によってこのプロセスが実行されていました。LINQ によってこのプロセスは宣言型になり、大きく前進しました。ただし、宣言型と言っても、ライブでも動的でもなく、ベースデータの変化に自動的に反応しません。結果的に、変更に対する反応は宣言型ではありません。プログラマが手続き型の命令コードによって変更に反応する必要があります。LINQ によって複雑性は低下しましたが、変更に対する反応は複雑なままです。変更は至るところで発生するため、変更に対する反応も広汎です。

LiveLinq のライブビューは、変更に対する反応も宣言型にすることで、宣言型の輪を完成させます。これで、GUI だけでなく、アプリケーション全体をほぼ完全に宣言型にすることができます。

小さな例を示すため、LiveLinqIssueTracker デモのサンプルを考えてみます。ある課題データに対して2つの操作を行います。

  1. 保留中の課題、製品の機能(機能に属するすべての課題)、および割り当てに関する情報を使用して、未割り当ての課題を可能な限り従業員に割り当てます。
  2. 指定された従業員の未解決の課題に関する情報を収集します。

この2つの操作(もちろん、実際のアプリケーションには、このような操作が多数存在します)はそれぞれ、結合を含むクエリーによって形成されたデータに作用します(「ライブビュー:ライブビューを使用して、手続き型コードではなく宣言型ルールセットとして非 GUI アプリケーションを作成する方法」を参照)。どちらの操作も、プログラムの実行中に複数回実行されます。データにこれらの操作および他の操作を実行する間も、データは変化します。これらの操作を実装するライブビューはデータの変化に伴って自動的に変更されるため、操作を単純かつ完全に宣言型に保つことができます。その結果、ビジネス要件の変化に対する堅牢性、信頼性、柔軟性、および変更の容易性が提供されます。

既に知っているライブビューの作成方法に関する知識以外に、このスタイルのプログラミングのために必要なことは何もありません。