eXpressApp Framework（XAF）のスマートフォーム。 パート2-メタモデルUIアプリケーション

最初の部分では、ビジネスエンティティのコードの属性を使用して、単純なビジネスルール（データ制御、強調表示の制御、フィールドのアクセシビリティと可視性）を追加することにより、eXpressAppフレームワークのフォームを「アニメーション化」する方法について説明しました。 このパートでは、別名Application ModelアプリケーションのXAFメタモデルを設定してこの問題を解決する方法について説明します。また、実際、このメタモデルが必要な理由と内部から構築する方法について説明します。

開発者によるメタモデルの拡張、ビジュアルエディターのモデルエディターを介したエンドユーザーによるメタモデルの編集など、幅広い可能性を忘れません。 また、この記事を読んだ後は、XAFメタモデルとXAFML記述言語、よく知られているすべてのCSSとXAML（QML、LSMLなど）、およびこれらの技術に組み込まれた詳細なアイデアの間にいくつかの類似点があると思います。 このような家庭用自転車の構造の珍しい製品について詳しく知ることを恐れない人は（ちなみに、マイクロソフトにアナログが登場する前に書かれた）、猫の下で歓迎してください。

ビジネスエンティティコードの属性と メタモデルの設定

したがって、前の記事の元のビジネスエンティティに何が起こったのかを批判的に見ると、さまざまな属性の豊富さから誰かを間違いなく怖がらせることができます。

1. [ DomainComponent ]
2. パブリック インターフェイス IAccount {
3. [ RuleRequiredField、RuleUniqueValue ]
4. [ RuleRegularExpression （ @ "^ [_ a-z0-9-] +（。[_ A-z0-9-] +）* @ [a-z0-9-] +（。[A-z0-9-] +） *（。[az] {2,4}）$ " ） ]
5. 文字列メール{ get ; セット; }
6. [ FieldSize （ 25 ） ]
7. [ ImmediatePostData ]
8. [外観（ "MarkUnsafePasswordInRed" 、 "Len（パスワード）<6" 、FontColor = "Red" ） ]
9. string Password { get ; セット; }
10. }
11. [ XafDefaultProperty （ "FullName" ） ]
12. [ DomainComponent、ImageName （ "BO_Person" ） ]
13. パブリック インターフェイス IPerson {
14. 文字列 LastName { get ; セット; }
15. 文字列 FirstName { get ; セット; }
16. [計算済み（ "Concat（IsNull（FirstName、 ''）、 ''、IsNull（LastName、 ''））" ]
17. 文字列 FullName { get ; }
18. DateTime Birthday { get ; セット; }
19. }
20. [ DomainComponent ]
21. パブリック インターフェイス IOrganization {
22. [ RuleRequiredField ]
23. 文字列 Name { get ; セット; }
24. [集計]
25. IList < IPerson > Staff { get ; }
26. [ RuleRequiredField （ TargetCriteria = "Staff.Count> 0" ） ]
27. [ DataSourceProperty （ "Staff" ） / *、DataSourceCriteria（ "StartsWith（FirstName、 '123'）"）* / ]
28. [外観（ "ChangeManagerAvailabilityAgainstStaff" 、 "Staff.Count = 0" 、Visibility = ViewItemVisibility。Hide、Context = "DetailView" ） ]
29. IPersonマネージャー{ get ; セット; }
30. }

ビジネスエンティティのコードでユーザーインターフェイスの外観と動作を直接指定する属性を豊富に使用することは、「パスアンドフォーゲット」プロジェクトの開発速度を大幅に向上させるのに役立ちますが、大規模プロジェクトではそれほど便利ではありません。 また、eXpressApp Frameworkアセンブリへの参照が望ましくない可能性があるシナリオも忘れないでください（たとえば、ビジネスエンティティの同じライブラリを使用するが、そこに「左」属性がないXAF以外のプロジェクト）。 最後に、上記のコードの読みやすさと悪臭の可能性についても説明していません。



アプリケーションのユーザーインターフェイスの外観と動作を構成し、理想的にはインターフェイスから分離する必要のあるビジネスロジックに直接関連しない他の設定を保存するための別の集中管理された場所があれば素晴らしいでしょう。 別のレベルへの設定の部分的または完全な転送は、ユーザーインターフェースからビジネスロジックのカツレツとハエの分離のフォロワーの前にあなたの魂を浄化するだけでなく、コードをよりクリーンでシンプルにし、高度なビジュアルエディターを使用して開発プロセスをより快適にすることも可能です。



ただし、これらのアプローチの1つが理想的であり、他のアプローチの使用が禁止されていることを明確に言うことはできません。 それどころか、これらのアプローチはそれぞれ、開発者の武器庫での位置に値するものであり、プロジェクトの条件（サイズ、緊急度など）に応じて適用する必要があると確信しています。 たとえば、メインWebサイト（フロントエンド）は通常の（非XAF）ASP.NETアプリケーションであり、インターフェイスにビジュアルASP.NETコンポーネントを使用し、データアクセスにORMライブラリeXpress永続オブジェクト（XPO）を使用します。 同時に、ビジネスエンティティ（顧客、問題、バグレポート、質問など）を含むライブラリは、eXpressAppフレームワークへのリンクを持たず、XAFで記述されたいくつかの内部アプリケーション（バックエンド）で使用されますが、XAF固有の属性とエンティティを使用しません。 この場合、これらのビジネスエンティティの表現のすべての設定は、個々のXAFモジュールのメタデータを通じて行われます。

アプリケーションメタモデルまたはさらにタマネギ...

このようなXAFの設定のリポジトリは、UIの外観と動作を記述するメタデータのレイヤーであるアプリケーションモデルです。 技術的には、これは1つの層だけでなく、重ね合せの原理に従って（弓の頭のように）変化が互いの上に重なる層の集まりです。 最初の層、いわゆる「ゼロ」 保護リングは 、フレームワーク自体によって次のように形成されます。フレームワークは、プロジェクトを分析し、現在のモジュールに含まれるすべての接続されたビジネスモデル、コントローラー、チーム、エディター、およびその他のエンティティに関する情報を収集します依存関係。 次に、アプリケーションの種類について収集された情報から、実際には、オブジェクトの表示（ビュー）、ナビゲーションシステムとコマンド、ローカリゼーションなどを含むユーザーインターフェイスのすべての側面を規制する特別なメタデータが生成されます。

XAFアプリケーションの一般的なアーキテクチャにおけるメタモデルの場所をよりよく理解するために、小さな図を示します。







XAF用語におけるレイヤー間の変更または相違は、一般にモデルの相違と呼ばれます。 したがって、これらの違いを含むXMLモジュールファイルの名前は「Model.DesignedDiffs.XAFML」です。 各レイヤーのコンテンツをいくつかの方法で変更できることに注意してください。



1.特別なビジュアルエディター- モデルエディター ;

2. XAFMLファイルを直接編集する。

3.プログラムコードを通じて。



すべてのレイヤーの重ね合わせにより、最終的なアプリケーションモデルが形成されます。







ここで、アプリケーションの「最終」モデルとは、開発者が何らかの要素またはそのプロパティを参照するときにコードで受け取るものを意味します。 また、メタモデル自体は「怠laz」です。 重ね合わせは、必要な場合にのみ計算されます。たとえば、ある種のユーザーインターフェイス画面を作成する必要がある場合、内部APIからの要求に応じて計算されます。 ここで、これらの計算はアクセスされるたびに行われるのではなく、実行中に正しくキャッシュされることに注意することが重要です。



ここではレイヤーについて詳しく説明していますが、フレームワークのフレームワークの外には非常に多くのアプリケーションやテクノロジーがあり、レイヤーがまったくないため、XAMLを例に挙げています。 したがって、XAFアプリケーションの多層メタモデルを作成する主な理由/要件を以下にリストします。



1.複数のプラットフォーム用にアプリケーションを柔軟に構成する機能。

2.実行時のアプリケーション構成による開発の加速。

3.標準動作を変更するカスタムモジュールの簡単な開発。

4.管理者が既にデプロイされたアプリケーションを一元的に構成する機能。

5.エンドユーザーのアプリケーションの外観と動作を個別に変更する機能（たとえば、アクセス権に基づいて動的に変更する機能）。

メタモデルの実用例

理論は十分だと思いますが、実際にメタモデルを使用してみましょう。 これを行うには、アプリケーションを再構築し、以前のアプリケーションのプラットフォームに依存しないモジュールのModel.DesignedDiffs.xafmlファイルをダブルクリックします（またはソリューションエクスプローラーのコンテキストメニューから対応するコマンドを呼び出します）。







これにより、上の図に示すように、モデルエディター（モデルエディター）が開きます。 簡単に言えば、このエディターは、左側にすべてのモデル要素があり、右側にプロパティインスペクターがあるツリーを備えたかなり「スパルタン」なインターフェースです（モデルレイヤーをすばやく検索、ローカライズ、マージするための組み込みツールもありますが、ここでは詳しく説明しません）英語のドキュメントに記載されています）。

この図から、メタモデルによって制御されるアプリケーションの側面をすばやく評価できます。 ところで、ここで見られるのは、現在のモジュールとその依存関係で見つかったタイプに従って、XAFによって生成されたモデルのゼロレイヤーの視覚的表現です。



フォームの1つの外観（ICustomer_ListView）を突然少し変更する必要があったと想像してください。 1つの列を削除し、別の列の並べ替えを設定し、列の順序を変更し、最後にアプリケーションをロシア語にローカライズすると、このXMLは対応するレイヤー（Habr.Module / ModelDesignedDiffs.XAFML）に保存されます。前のレイヤーとの違い：

1. <？xml version = "1.0" encoding = "utf-8" ？>
2. <アプリケーション タイトル = "HabrDemo" ロゴ = "ExpressAppLogo" >
3. <ビュー>
4. <ListView Id = "ICustomer_ListView" >
5. <コラム>
6. <ColumnInfo Id = "Name" SortOrder = "Descending" />
7. <ColumnInfo Id = "Email" Index = "1" />
8. <ColumnInfo Id = "Manager" Index = "2" />
9. <ColumnInfo Id = "パスワード" 削除 = "True" />
10. </列>
11. </リストビュー>
12. </ビュー>
13. </アプリケーション>

*スペースを節約するために、ここでは個別のXAFMLファイルが作成されるローカリゼーションを特に提供しません。



アプリケーションを実行すると、設定が期待どおりに適用されていることがわかります（列の並べ替えと並べ替えに注意してください）。







技術的には、これは（標準XAFモジュールからの）コードがメタモデルに変わり、それに応じてコントロールを構成したことを意味します。



特に、Visual Studioではなく、実行時にアプリケーションをセットアップするシナリオを強調したいと思います。 この場合、アプリケーションの実行中に行われたすべての設定は、最後のレイヤーであるユーザー設定レイヤーに分類されます。 デフォルトでは、この最後のレイヤーはModel.User.XAFMLファイルで表されますが、経験から、ほとんどの人はデータベース内のファイルストレージを好みます（将来的にはこれをデフォルトの動作にする可能性が高いです）。 強力なDevExpressコントロールのおかげで、アプリケーションのセットアップには特別なスキルやツールは必要なく、ほとんどの場合、エンドユーザー自身で実行できます。 たとえば、ユーザーは、視覚コントロール自体のツールを使用して、並べ替え、フィルターのグループ化、フォーム上のコントロールの場所、サイズなどを変更できます。 より細かな調整が必要で、上級ユーザーまたは開発者である場合、サービスにはモデルエディターがあり、実行時にも使用できます。

次に、ビジュアルエディターを使用して詳細なフォームをすばやくカスタマイズする方法を見てみましょう。 これはビデオよりもうまく証明できないと思います。



「ゴム」自動生成フォームの概念は、基本的に開発者の作業を楽にすることを目的としており、2つの主な問題を解決します。



1.開発段階でのフォームのより便利で迅速な構成

2.より便利な展開とアプリケーションサポート



最初の方法は、提案されたアプローチを使用すると、数百のフィールドを複雑な形に揃えるのに何時間も費やす必要がなく、ビジネスモデルに新しいフィールドが表示された場合にすべてをやり直す必要があるためです。 メタデータはビジネスエンティティに基づいて動的に生成されるため、開発中にビジネスモデルを自由に変更でき、変更がアプリケーションモデルに自動的に影響することを確認できます（もちろん、ビジネスエンティティの変更をフォーム設定に「修正」する機会がありますそれらには影響しませんでした）。



2番目の方法は、フォームのカスタマイズをエンドユーザーまたはアプリケーション管理者に提供する機能により可能です。このタスクは実行時に完全に実行できるためです。 マルチレイヤーアプリケーションモデルにより、管理者レベルで（技術的にはモデルの一部のサブレイヤーで）必要な変更を一度行うことで、エンドユーザーアプリケーションの設定を一元的に変更できます。

カスタム設定をメインアプリケーションまたはモジュールの一部にするには、組み込みモデルエディターの特別な拡張機能であるModel Merge Toolを使用できます。







このツールを使用すると、メタモデルのソースレイヤーとターゲットレイヤーを選択し、実際にそれらを1つにマージできます。

メタモデルの内部構造と拡張についてもう少し

上記では、XAFMLファイルの一部を示しました。おそらく、アプリケーション、ビュー、リストビュー、およびメタモデルの別個の要素であるその他の要素に気づいたでしょう。 内部では、これらの要素は、最初の記事で既に知られているドメインコンポーネント（DC）テクノロジを介して実装されます（厳密には、Silverlightから完全な.NETとほぼ同じ方法で主要なものを参照する軽量バージョンを通じて）：

1. パブリック インターフェイス IModelListView ： IModelObjectView、IModelView、IModelNode
2. {
3. IModelColumns Columns { get ; }
4. [ DataSourceProperty （ "Application.Views" ） 、DataSourceCriteria （ "（AsObjectViewはNullではない）および（AsObjectView.ModelClassはNullではない）および（ '@ This.ModelClass'はNullではない）および（AsObjectView.ModelClass.Name = '@ This.ModelClass.Name '） " ） ]
5. IModelDetailView DetailView { get ; セット; }
6. [ DataSourceProperty （ "ModelClass.ListEditorsType" ） ]
7. EditorType { get ; セット; }
8. IModelSorting Sorting { get ; }
9. bool UseServerMode { get ; セット; }
10. ...およびオブジェクトのリスト（リストビュー）でフォームを特徴付けるその他のプロパティ
11. }

おそらくDCの主な機能から既に理解しているように、モデル要素を表すすべてのロジックとフィールドを持つ実際のクラスは、インターフェイスと関連する特別なロジッククラスから動的に組み立てられます。 上記で、モデルでの計算値のキャッシュについては既に述べましたが、動的タイプの生成は非常に高速な操作ではないため、アプリケーションのロードを高速化するキャッシュもあります（特にこれらのタイプが数百および数千ある場合）。 つまり、動的モデルタイプのアセンブリは、アプリケーションが最初に起動されたときに一度だけ発生します。 次に、実行可能ファイルの横にある特別なModelAssembly.dllアセンブリに保存されます（ちなみに、DCでも同じことが行われ、 DcAssembly.dllにのみ入ります ）。 次に、通常どおりこれらのアセンブリから型が直接読み込まれます。 ちなみに、これらの2つのアセンブリをReflectorで遅延させて開いて、これらすべてのインターフェイスが何に変わったかを確認してください:-)



モデル要素の標準セットは、デフォルトで新しいXAFプロジェクトに接続するシステムモジュールから取得されます。 レイヤーは異なる「スキーマ」（XMLの場合）を持つことができることに注意してください。 アプリケーションモデルの要素のアクセス可能なセットまたはスキーム。これは、レイヤーの構築に使用されるモジュールに直接依存します。 したがって、たとえば、プラットフォームに依存しないモジュールでリストビュー構造を定義するアプリケーションモデル要素であるIModelListViewがあります。 プラットフォーム固有の要素であるIModelListViewWebとIModelListViewWinもあり、オブジェクトのリストでフォームを特徴付ける独自のプロパティセットがあります。 実際には、これは、Webモジュール（Habr.Module.Web / ModelDesignedDiffs.XAFML）のモデルエディターを開くと、新しい要素とオプション、たとえばSaveListViewStateInCookiesが表示されることを意味します。



このスキームは、追加機能を実装するときに開発者の裁量で拡張できることが重要です。 たとえば、標準のリストビュー要素（またはコードを所有していない他の要素）を設定するための独自のオプションを追加するには、次のコードをモジュールに追加します。

1. パブリック インターフェイス IModelListViewEx {
2. 文字列 MyCoolOption { get ; セット; }
3. }
4. public override void ExtendModelInterfaces （ ModelInterfaceExtenders extenders ） {
5. ベースの ExtendModelInterfaces （エクステンダー） ;
6. エクステンダー。 追加 < IModelListView、IModelListViewEx > （ ） ;
7. }

要素コードを所有している場合、このオプションをインターフェイスに追加するか、インターフェイス拡張を明示的に「ミックス」します。

1. パブリック インターフェイス IModelLayoutViewItem ： IModelLayoutItem、IModelViewLayoutElement、IModelLayoutElementWithCaptionOptions、IModelNode、ISupportControlAlignment、IModelToolTip、IModelToolTipOptions

もちろん、開発者は、ゼロレイヤーの生成（実際には、標準およびカスタムモデル要素の独自のジェネレーターを作成できます）、動作のカスタマイズ、モデルエディターでの表示など、モデル構築の他の側面を柔軟に制御できます。

おわりに

結論として、主にこのような強力なマルチレイヤーおよびダイナミックメタデータレイヤーが存在するため、フレームワークは同じコードベースを使用して複数のプラットフォームのアプリケーションインターフェース（「UI Scaffolding」という流行語を挿入せざるを得ません）を自動的に構築できます一般的に、これらはビジネスエンティティ、コントローラー、チーム、ユーザーエディターなどです。 したがって、私たちのケースでは、数分のうちに1つのビジネスエンティティICustomerしか持たず、WindowsとWeb用のアプリケーションを作成および構成しました。 また、一般に、主にメタモデルの機能のおかげで、これらのプラットフォームのよく知られている欠点を平準化または隠すことによって、一部のWindowsフォームおよびWebフォーム開発者の生活を改善しています。 したがって、XAFを使用すると、開発者はXAMLの楽園から「グッズ」の類似物を取得できますが、新しいものを学ぶことに投資することなく、開発アプローチを完全に変更することなく、古き良きプラットフォームに留まることができます。何年も経った今もXAFへの関心が安定していることを説明してください。



もちろん、マイナス面もいくつかありましたが、ユーザーのことではなく、このすべての開発者として、彼らは私たちだけに関係しています。 実際、私たちのチームの少数の人々は、数千のブロックテストと機能テストにもかかわらず、手を洗わずに祈ることなく、メタモデルエンジンのコアのバグを修正することを請け負います-エラーを犯したり、少なくとも誤ってパフォーマンスを悪化させるリスクが多すぎます。 魂を喜ばせずにはいられない唯一のことは、フレームワークの6年の歴史にわたって、すべての小児疾患がすでに治癒しており、カーネル領域にほとんどバグがないという事実です:-)



そして最後に、 ドキュメントの多数の記事 （英語）で、アプリケーションメタモデルの機能、その拡張と構成の方法、およびXAFフレームワーク自体について詳しく知ることができます。 前回のDevConでのプレゼンテーションでこのビデオに興味を持つ人がいるかもしれませんが、時間の制約のため、製品とその機能の非常に一般的な概要を説明する必要があったことを警告します。