Visual Studio 2012
Visual Studio LightSwitch 2012 でデータを整える
Visual Studio LightSwitch は、デスクトップやクラウド向けにビジネス アプリケーションをビルドする最も簡単な方法として、2011 年半ばに初めてリリースされました。IT に見識のある多くのユーザーがすぐに使い始めたものの、熟練の開発者の一部は、LightSwitch をエンタープライズ向けに使用するには時期尚早だとあっさり見切りをつけました。結局、迅速なアプリケーション開発テクノロジは、新規かつ小規模なアプリケーションにすぐに着手するには優れた方法ですが、すばやく作成されたアプリケーションは規模が拡大するにつれて適切にスケール変換されず、既存のレガシ システムと相互運用するには多大な労力が必要で、ペースの速いテクノロジの変化に対応できず、マルチテナントのインストールや多くのユーザーによる同時実行などのエンタープライズ要件を処理できないことは、残念ながら歴史が証明しています。そのうえ、ほとんどすべての大規模 IT 組織で RESTful サービスや HTML クライアントなどのオープン標準が採用されている時代に、クローズド方式に縛り付けられたいと望むユーザーなどいるでしょうか。
LightSwitch 2012 のリリースが近づいたので、何人かの友人 (熟練開発者やソフトウェア アーキテクト) の先入観を取り除き、LightSwitch がこうした現代の要求に対応する方法を (再び) 評価してもらうには最高のタイミングだと考えました。
結果はどうでしょう。LightSwitch 2012 はこうした要件に対応できるだけではなく、みごとにやってのけることがわかりました。
Visual Studio LightSwitch について
LightSwitch は、データ中心のサービスやアプリケーションの操作を支援するために、デザイナーを基盤として Visual Studio 2012 に追加されています。LightSwitch プロジェクトを操作するときは、Visual Studio IDE が主なエディターを 3 つだけ備えた開発環境に変化します (いわゆる「論理モード」)。この 3 つのエディターが、エンティティ デザイナー、クエリ デザイナー、およびスクリーン デザイナーです。これらのエディターは、非常に直感的で、簡単かつ迅速に使用できるようにすることで、すばやく結果を得ることに重点を置いています。これにより LightSwitch の開発者にとって、次のいくつかの明らかなメリットがもたらされます。
- まず、プラミング (情報システムの開発に関連する典型的な反復コード) を目に付かないようにします。エディターが使いやすければ開発が迅速になり、開発が迅速になれば開発者の生産性が向上し、そして開発者の生産性が向上すればビジネスの価値が高まります。つまり、Scott Hanselman のことばを借りれば、「非常に大きなものをスケール変換するには、できる限り労力を少なくします。実際、かける手間が少ないほど、できることが増えます」(bit.ly/InQC2b、英語)。
- 次に、おそらく最も重要なことですが、機能のアナリスト、中小企業の事業主、Microsoft Access や Microsoft Excel を使用し、ビジネスに精通している "開発者" (市民開発者とも呼ばれます) など、技術の専門家ではない広範なユーザーがアプリケーションの開発に加わって手助けすることができ、さらにはすべての開発を行うことさえ可能です。エディターは、技術上の選択を望まないユーザーに選択肢を見せないようにし、ドメイン ロジックを再利用可能なドメイン モデルにカプセル化する、UI スレッド以外のスレッドでビジネス ロジックを実行し UI の応答性を確保する、クライアントでモデル - ビュー - ビューモデル (MVVM: Model-View-ViewModel) 開発パターンを適用するといったベスト プラクティスにアプリケーション デザイナーを自動的に導きます。
- 最後に、これらのエディターは実際にはクラスを直接編集しません。代わりに、メタデータ (LightSwitch Markup Language) を含む XML ファイルを操作します。このファイルは、その後 MSBuild のカスタム タスクが使用して、コンパイル中にコードを生成します。これは、技術上の選択を行って、ビジネス ロジックに投資する必要性を事実上取り除きます。たとえば、バージョン 1.0 で作成された LightSwitch プロジェクトはクライアントとサーバー間のすべての通信に WCF RIA サービスを使用していましたが、同じプロジェクトは Open Data Protocol (OData) サービスを使用するようにコンパイルされるようになります (OData の詳細については後で説明します)。これは、変化しつづける IT の世界にアプリケーションが適応できる最善と言ってよい方法です。
データを設計する
LightSwitch を使ったデータの設計は、熟練の開発者によると、ドメイン モデルを作成することに相当するそうです。IDE は、まず "データの開始"、具体的には、データを格納する場所をたずねます。これには 2 つの回答が可能です。[新しいテーブルの作成] を選択すると、LightSwitch は Entity Framework を使用して SQL Compact (アプリケーションのデバッグ時)、SQL Server、または Windows Azure SQL データベースに必要なテーブルを作成します。または、SharePoint、OData サービス、既存のデータベース、WCF RIA サービス アセンブリなどの既存のデータ ソースからエンティティを設計することも選択できます。最後の 2 つは、レガシ アプリケーションの既存のデータ セットを使い続けながら、まったく新しいサービスやアプリケーションの現代的なオープン標準でデータ セットを公開するのに非常に役立ちます。
たとえば、既存の OData サービス (例の包括的な一覧は odata.org/ecosystem (英語) から利用できます) を取得し、1 つまたは複数のエンティティを新しい LightSwitch アプリケーションにインポートできます。
図 1 は、Northwind データ ソースの Employee エンティティが最初にエンティティ デザイナーに表示されるところを示しています。何度かクリックし、必要な箇所で最小限のコードを作成することで、エンティティをいくつかの方法で再設計できます (最終結果は図 2 で確認できます)。この操作を次に示します。
- プロパティの名前を変更し、並べ替えます (TeamMembers と Supervisor)。
- 限られた数の定義済みの値しか受け取らないプロパティの選択リストを設定します (City、Region、PostalCode、Country、Title、および TitleOfCourtesy)。
- 新しいプロパティまたは計算プロパティを追加します (NameSummary)。
- プロパティのデータ型に、詳細なビジネス型を対応付けます (BirthData、HireDate、HomePhone、Photo、および PhotoPath)。
.png)
図 1 既存の OData サービスからインポート後のエンティティ デザイナー
.png)
図 2 再設計後の同じ Employee エンティティ
LightSwitch は、E-mail Address や Phone Number などのよく使用するビジネス型の多数のセットを認識します。このようなビジネス型は、多くの使用可能な拡張機能にあります。また、LightSwitch 拡張プロジェクトを使って独自のビジネス型を作成することもできます。基盤となるデータ型に関して、ビジネス型は、特殊な検証 (たとえば、E-mail 形式や Web Address 形式の確認)、特定の拡張プロパティ (Phone Number ビジネス型用の Phone Number 形式) など、特定の性質を持つプロパティを拡張し、多くの場合、クライアントのアプリケーションのプロパティを表すまたは操作するのに (既定で) 使用する特殊なコントロールを伴います。
エンティティが互いにまったく関連がないとは考えられません。エンティティ デザイナーを使用すれば、必要に応じてさまざまなエンティティの関係を設計できます。これらの関係は、SQL Compact、SQL Server、Windows Azure SQL データベースなどの組み込みの (新しい) データ ソースに格納されるエンティティを設計する際に、クライアントと中間層のコード、およびデータベースの外部キーを介してすべての層で設定されます。
ただし、LightSwitch の真に強力な機能は、既存のデータ ソースでも同様に新しい関係を定義できることです。これは、XML ファイルや、インデックス、キー、または適切な関係のない古くて不完全なデータベースなどの既存のデータ セットを活用しようとするときに特に役立ちます。これらのいわゆる仮想の関係は、レガシ データ ソースを実際に変更する必要なく、クライアントと中間層で適用されます。さらに強力なのは、これらの仮想の関係はデータ ソースが異なるエンティティ間で定義できることです。
たとえば、ソリューション エクスプローラーで [データ ソース] を右クリックし、[テーブルの追加] をクリックすると、新しいデータベースに格納される新しい Holiday エンティティを作成でき、Northwind OData サービスの Employee エンティティと仮想の関係を持ちます (図 3 参照)。
.png)
図 3 異なるデータ ソース間の仮想の関係
ここでは、1 つのアプリケーションだけでデータを使用して、他のアプリケーションに追加の値を提供することに伴う障壁を取り払うのに LightSwitch がどのように役立つかを示すために、休暇管理アプリケーションを作成します。
データを形成する
LightSwitch は、着手するのに必要なコード量を最小限に抑えることを試みて、初期開発をの速度を大幅に向上します。データ サービスを本当に公開できるようになるには、多くの場合、データ内部にビジネスを形成するためにいくつかの調整と修正が必要になります。エディターを使うよりもコードで表す方が簡単な場合がよくあります。
想定できるすべてのイベントのために、LightSwitch にはデザイナーの [コードの記述] からアクセスできる拡張ポイントがあります (図 4 参照)。サーバーでコードが呼び出されるかどうかによって、クライアントまたは両方の層で、LightSwitch プロジェクトのクライアント サブプロジェクト、共通サブプロジェクト、またはサーバー サブプロジェクトのいずれかでカスタム コードを実装できるメソッド スタブを生成します。
.png)
図 4 多くの拡張ポイントをサポートする LightSwitch
休暇管理アプリケーションの例を続け、これらのコード拡張ポイントを使用してエンティティを初期化します。たとえば、次のコードは、従業員の上司を休暇の承認者として自動的に割り当てるか、上司がいない従業員は休暇を承認します。
public partial class ApplicationDataService
{
// Initializing a new Holiday - server only
partial void Holidays_Inserting(Holiday entity)
{
if (entity.Employee.Supervisor != null)
entity.ApprovalBy = entity.Employee.Supervisor;
else
entity.Approved = true;
}
}
同様に、これらのコード拡張ポイントは、既に検証機能を備えたプロパティのビジネス型であっても、カスタムの検証コードを作成するのに役立ちます。
public partial class Holiday
{
// Determine if an "EndDate" is valid - executes client and server
partial void EndDate_Validate(EntityValidationResultsBuilder results)
{
if (StartDate > EndDate)
results.AddPropertyError("End date must follow the start date");
}
}
カスタムの検証とビジネス ルールに加えて、LightSwitch には、ロールとアクセス許可に基づくオプションのアクセス制御モデルが組み込まれています。アクセス制御の確認は、これらのコード拡張ポイントから、垂直方向にも水平方向にも行えます。
垂直方向のアクセス制御では、現在ログインしているユーザーのアクセス許可を基準に、画面、エンティティ、またはプロパティ単位に制限を課します。たとえば、次のコードは、承認プロセスを人事部などの組織の特定部門の従業員のみに制限します。
public partial class Holiday
{
// Determine if "Approved" can be modified by the user -
// executes client and server
partial void Approved_IsReadOnly(ref bool result)
{
result = !Application.User.HasPermission("ApproveHolidays");
}
}
水平方向のアクセス制御では、エンド ユーザーに表示されるレコードをフィルター処理します。次のコードはサーバー層で実行されることに注意します。つまり、エンド ユーザーにアクセスが許可されていないデータがネットワーク経由で送信されることはありません。
public partial class ApplicationDataService
{
// Filtering out records - runs on the server only
partial void Holidays_Filter(ref Expression<Func<Holiday, bool>> filter)
{
if (!Application.Current.User.HasPermission("ViewAllHolidays"))
filter = holiday => holiday.Employee.NameSummary ==
Application.Current.User.FullName ||
Application.Current.User.FullName == holiday.ApprovalBy.NameSummary;
}
}
水平方向のアクセス制御は行レベルのセキュリティとも呼ばれ、Visual Studio 2012 の LightSwitch への重要な追加です。
まず、サーバーでフィルター処理が実行されます。これにより、呼び出しのたびに転送される不必要なデータの量を制限します。これは、ユーザーがそもそもそれらの行の操作を許可されていないためです。垂直方向のアクセス制御では、エンド ユーザーが操作できないデータも表示されます。これは、制御が読み取り専用か、違反行為の場合は例外がスローされるためです。ただし、水平方向のアクセス制御の場合、余分なデータがエンド ユーザーに表示されることはありません。
これにより、行レベルのセキュリティの別の強力な使い方が可能になります。データ セット全体の一部の所有権だけを、特定のユーザーや組織に提供できます。これにより、1 回だけインストールするアプリケーションを作成でき、さまざまなグループ、企業、個人、または組織にアクセスを提供できます。それぞれはテナントとして機能し、すべてが同じクライアント アプリケーションやサービスを使用しますが、データの一部しか所有しません。これらのマルチテナントのインストールは、すべての当事者のホストにかかる経費を大きく抑え、クラウドなどの中央の場所で 1 回だけ更新する機能など、他のメリットを提供します。LightSwitch 2012 のマルチテナント機能の有用性を最初に認識するのは、おそらくオンサイト サーバーに何時間も電話して、緊急の修正プログラムのインストールを繰り返し更新していた担当者でしょう。
データを公開する
企業が収集したデータの価値について検討するとき、多くの開発者は、データを使用する製品の観点からしか考えない傾向があります。ただし、幅広いカテゴリのデータを収集して分析するのは、以前にも増して価値あることになっています。1 つのアプリケーションだけでデータを処理することにとらわれず、データを適切に処理すると、データの分析やデータ マイニングによって、従来の製品ベースのビジネス モデルを超える新たなメリットがもたらされます。これを実現するには、LightSwitch プロジェクトをビルドするときに自動的に構築されるサービスで使用するプロトコルを、OData プロトコルなどのオープン標準にすることが重要です。
次に、odata.org (英語) の OData に関する要約を示します。
「OData はオープン データ プロトコルの略で、データの照会と更新用の Web プロトコルです... OData は HTTP、Atom Publishing Protocol、JSON などの (オープンな) Web テクノロジを適用してビルドすることでこれを行います... OData は Web と動作方法が一貫しており、URL をリソースの認証と深く関連させ、リソースを操作する HTTP ベースの統一されたインターフェイスにコミットします (Web と同様)。この中核となる Web 原理との密接な関係によって、OData は新しいレベルのデータ統合と、幅広いクライアント、サーバー、サービス、およびツールをまたがる相互運用を可能にします。」
言い換えると、OData はシンプルな HTTP 動詞とリソースの識別子 (または URL) を使用して操作できるサービスを実装しています。OData サービスは、ほぼすべてのクライアント テクノロジから最もシンプルな方法で使用できます。たとえば Web アドレスとして次のように入力することで、Web ブラウザーから HTTP の "Get" 要求でサービスを参照することさえ可能です。
http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=
replace(CompanyName, '%20','')eq'AlfredsFutterkiste'
こうした URL は、必ずサービスのルート URL (サービスのエンドポイント)、リソースのパス (エンティティの名前)、および選択可能なクエリ オプションから構成されます。後者はサービス自体をユース ケースから十分に独立させることに注意します。つまり、OData プロトコルには、URL を介してデータを並べ替えたりフィルター処理したりするのに使用できる詳細なクエリ言語がありますが、呼び出し元がこれを必要とします。演算子の完全なセットは、bit.ly/LSiPAj (英語) から利用できます。
LightSwitch データ サービスを設計するときに、データをどのように使用するかを認識していれば、自身にとって便利なように、クエリ デザイナーを利用して発行前にクエリを作成することもできます。図 5 に示すのは、現在の年に始まる未承認の休暇のみを返すシンプルなクエリです。クエリのソースは完全な Holidays のセットで、当然ながら既にコードで設定したフィルターで事前にフィルター処理されます。
.png)
図 5 クエリ デザイナーを使用したシンプルなクエリの作成
エンティティ デザイナーとクエリ デザイナーにいくらか時間を費やすと、OData サービスの配置準備が整います。これは、Visual Studio IDE から直接実行でき、ソリューション エクスプローラーで LightSwitch のプロジェクトを右クリックし、コンテキスト メニューから [発行] をクリックします。
これにより、LightSwitch アプリケーション発行ウィザードが表示され (図 6 参照)、これで必要な接続文字列、認証の種類 (認証なし、ユーザー名とパスワードの組み合わせ、または Windows 認証)、アプリケーションの管理者アカウント、およびインストール先 (インストール パッケージとして、または IDE から IIS か Windows Azure への直接発行を伴う) などの最後のアプリケーション固有のプロパティをいくつか設定できます。最後のオプションは、ここ数か月間で特にいくつかの大きな強化が加えられ、迅速かつ安心してデータ サービスをクラウドに配置できるようになっています。
.png)
図 6 LightSwitch 発行ウィザード
オープン標準を採用することで、データ サービスを操作するのに使用できるクライアントのセットは、既にほとんどのエンド ユーザーが使用できるようになっています。Microsoft Excel のようなスプレッドシート アプリケーションを使えば、コード作成の必要なく、データ サービスを使用して、PowerPivot テーブルやグラフに変換できます (図 7 参照)。(注: PowerPivot は、Office 2013 に組み込まれていますが、Office 2010 では個別の無料アドオンです)。これについての順を追ったチュートリアルは、bit.ly/xETG0V (英語) から見つけられます。
.png)
図 7 Excel での LightSwitch OData サービスの使用
クライアントをビルドする
LightSwitch のもう 1 つの主なメリットは、クライアント アプリケーションをビルドするのにも同じ IDE エクスペリエンスを使用できることです。LightSwitch は、シック クライアント (ブラウザー内またはブラウザー外の Silverlight 5) とモバイル コンパニオン アプリケーション (HTML5) の両方を、サーバー側で提供するのと同じ設計速度かそれ以上の速度でサポートします。HTML5 アプリケーションを作成する機能は、プレビュー リリースでのみ利用できますが、最終的な Visual Studio 2012 のリリース後にアドオンとして利用できるようになります。
開始するには、エンティティ デザイナーかクエリ デザイナーのどちらかで [画面の追加] をクリックします。これによって画面テンプレートを選択できるウィザードが表示され、多くの組み込みのテンプレートの 1 つ、または独自に作成するか、利用可能な拡張機能からダウンロードしたテンプレートを選択できます。
画面データ (Holiday エンティティ セット) とテンプレート (一覧と詳細画面) を選択すると、目的の画面レイアウトがすばやく生成され、スクリーン デザイナーで開きます。コントロールのレイアウトにいくつか初期の変更を加えるか、使用するコントロールをまったく作り変えることから開始できます。LightSwitch には、誕生日プロパティには日付選択を使用するなど、プロパティのビジネス型に基づき、使用するコントロールを推測する優れた機能がありますが、これは他の組み込みまたは利用可能な拡張からダウンロードした LightSwitch コントロールに自由に変更できます。または、XAML (または JavaScript と CSS) のスキルを活かして、好きなようにカスタマイズできます。この時点で、アプリケーションは F5 キーをクリックしてビルドして実行する準備が整いました。
図 8 に示すように、アプリケーションは見やすく、直感的で、非常に機能的です。ただし、簡単に作成できるからといって、不完全なものだと思わないでください。たとえば、内部では、メタデータのランタイムの解釈に基づき、高度なバージョンの MVVM を使用します。これについては、2012 年 5 月号の記事「LightSwitch MVVM モデル」で取り上げました (msdn.microsoft.com/magazine/hh965661)。このため、Visual Studio で最初の設計に使用したスクリーン デザイナーは、画面右下のデザイン スクリーンのリンクをクリックしてアプリケーション内に呼び出せ、アプリケーションがデバッグ モードで実行している間にメタデータの表示にさらに変更を加えられます。これらの変更は、プロジェクトにも保存されます。
.png)
図 8 シンプルな LightSwitch クライアント アプリケーション
LightSwitch クライアント アーキテクチャについてさらに調べると、まだまだ技術的に驚くことがたくさんあります。たとえば、基盤となるエンティティを編集するアクセス許可がない場合は、コントロールや画面は自動的に読み取り専用または非表示になります。
同じように便利なのは、NotifyPropertyChanged イベントを自身で発生させて正しい関数にバインドすることを懸念する必要がなくなったことです。たとえば、エンド ユーザーが従業員のエンティティの姓名のプロパティを変更する場合、処理されたフルネームのプロパティ (当然ながら姓名のプロパティに基づく) にバインドされたコントロールは、自動的に更新され新しい値を表示します。
プロパティの変更について説明します。クライアントで使用するすべてのモデルは、実際にはビジネス ロジックを処理する間に UI の応答性を確保するのに役立つ "デュアルディスパッチャー オブジェクト" です。UI スレッドから、値をプロパティに簡単に割り当てられます。これは、内部で通知を送信し、論理スレッドと呼ばれる 2 つ目のスレッドで重み付けの優先順位に基づき取り出されます。ビジネス ロジックが処理を完了したら、同じイベント通知システムを使用して UI スレッドに最終的な結果を伝え、それに従い UI を更新します。
クライアントに関して共有する必要のある最後の興味深い事実は、各画面は実際には作業単位を表していることです。これは、頻繁に更新されている Visual Studio LightSwitch チーム ブログで説明されています (bit.ly/9vENdF、英語)。各画面には固有のデータ ワークスペースがあり、ポップアップやエンティティの詳細画面など、その初期画面から開くすべての子画面を共有します。すべての変更は、エンド ユーザーが保存またはすべての破棄を決めるまでローカルに保存されます。つまり、画面を 2 回開くことで (複数インスタンスの許可は既定で無効になっていますが、スクリーン デザイナーの [プロパティ] ウィンドウで有効にできます)、複数のユーザーが同時にデータに変更を加え、同時に保存するのを LightSwitch がどのように処理するのかをシミュレーションできます (図 9 参照)。
.png)
図 9 同時変更の処理
LightSwitch がどの程度適切にこれを処理するでしょうか。冒頭でも述べたように、これらすべての要件を単に処理するだけでなく、みごとにやってのけます。
Jan Van der Haegen は、コーヒーをソフトウェアに変換するエコ志向のおたくです。彼は愛妻家で、ベルギー中部の国際的なチームにおける誇り高きスクラムの達人でもあり、特に Visual Studio LightSwitch などのあらゆる .NET テクノロジについて学習することに夢中で、コードの実験に関するブログを書いています。彼の最新の試みは、switchtory.com/janvan (英語) から見つけられます。
この記事のレビューに協力してくれた技術スタッフの Joe Binder と Beth Massi に心より感謝いたします。