あなたは知りませんが、私はこの写真で自分自身を認識しました。 実際、アプリケーションアーキテクチャが設計されているとき、すべてが美しく、論理的であり、世界のベストプラクティスに沿っていることを認めなければなりません。 しかし、作業の過程で、アーキテクチャによって課せられる制限に直面して、私たちはしばしば考えます。「ここで少し違反します。1時間の開発時間を節約できます。 それでは、時間が経てば修正します。」 しかし、何らかの理由で、今回は決して来ません。 私の意見では、プログラマとして自分が開発されたアーキテクチャに従うよう強制する唯一の方法は、開発環境にすべての逸脱と松葉杖を教えてコンパイルエラーとして表示することです。 この場合、コードが悪い場合、すぐに修正されますが、アーキテクチャが古い場合は修正されます。 つまり コードリポジトリには、計画されたアーキテクチャに対応するコードが常に存在します。
タックルについてのいくつかの言葉：
1.小さなプリアンブル。
2.既存のプロジェクトに応じたアーキテクチャの復元。
3. Visual StudioおよびTFSを自動アーキテクチャ制御用に構成します。
カットの下で多くの写真と説明されたすべてを試してみたいという願望。
だから、約束された前文。 ほぼ1年前、Dmitry Andreev（ dmandreev ）はすでにこのトピックに関する記事を公開しています。 私はこの記事を非常に喜んで読んでおり、実際、アプリケーション開発プロセスでレイヤー図を使用する問題に対処するよう促したのは彼女でした。 ところで、この場所を読んで、あなたはすでにリンクをたどって、Dmitryが書いたものを読んだことがありますか？ いいえ、それではまあ、待って、あなたを待って、次に進みましょう。 待っています。
さて、あなたと私がレイヤー図について共通の理解を持っているので、前文で終わり、実際の作業に進むことができます。
デモプロジェクトの準備
レイヤー図を使用した作業を示すために、Dmitryが検討したよりも現実に少し近いプロジェクトを取り上げます。 データアクセスレイヤー（Entity Frameworkを使用します）と、実際には、レイヤー構造（MVVM）もあるクライアントアプリケーションレイヤーを用意します。 クライアントレベルでは、モデルは最初のレイヤーから取得されますが、ViewレイヤーとViewModelレイヤーは複数のアセンブリに分散されます。
したがって、これらの4つのプロジェクトは作成後に面倒をみます。
作成されたアセンブリのデフォルトの名前空間はすべて変更されると思いますか？ さて、この例では、3つのクライアントアセンブリについて、既定の名前空間を置き換えます。
データベースとエンティティモデルをDALプロジェクトに追加します。 クライアントプロジェクトで、ViewおよびViewModelフォルダーを作成します。 テストコンポーネントとテストクラスを追加します。
プロジェクト間のリンク、作成されたコンポーネントとクラス間の呼び出しを追加することにより、次のような依存関係グラフを取得できます。
アセンブリレベルで階層化が発生する場合、アセンブリ間の循環リンクが禁止されているため（そうでない場合は、構築順序を決定することはできません）、唯一の問題は「レイヤーを介したアクセス」です（まさにDmitryの記事で説明されています）。 この場合のように、プロジェクト内でレイヤーが複数のアセンブリにまたがっていて、同じアセンブリ内に異なるレイヤーの代表がある場合、ソリューションエクスプローラーからレイヤー図にプロジェクト/ファイルをドラッグすることは効果的ではありません。 そして、アーキテクチャエクスプローラがメインメニューから呼び出されます：アーキテクチャ-> Windows->アーキテクチャエクスプローラ。 開いた直後は次のようになります。
率直に言って、私が初めてこのツールについて読んだとき、私はすぐにそれを好きになりました。 まさに息をのむような依存関係分析のためのそのような機能。 そして、あなたはそれについて多くのことを熱心に書くことができますが、それはあなたがアーキテクチャを自動的に制御することを許さないので、もう一度それについてさらにそれについて。
ソリューションアーティファクトからレイヤー図を復元する
シーンの準備ができたら、アクターをリリースします。 モデルプロジェクトをソリューションに追加し、レイヤー図を追加します。
はい、ここでは、ツールボックスからレイヤーをドラッグし、依存関係を描画し、クライアントプロジェクトからこれらのレイヤーにクラスを長くハードに転送できます。 そしてこれは、開発者が知らない新しいクラスを追加し、レイヤーにアタッチされていないため、チェックが機能しなくなるためです。 これを回避するには、便利なArchitecture Explorerを使用します。
すべてのViewModelクラスは同じ名前空間にあり（実際のプロジェクトでは3〜5になります）、クラスではなく名前空間全体をレイヤー図に追加できることに注意してください。 それらを選択し、レイヤーを作成せずにレイヤー図にドラッグします：
ところで、ソリューションエクスプローラーからプロジェクトのドラッグアンドドロップ機能を使用できます。 ShiftでClientApp1、ClientApp2、Base.Libraryを選択し、マウスの左ボタンでそれをつかみ、レイヤー図の空の場所にドラッグします。
新しいレイヤーの名前をプレゼンテーションに変更し、2つのレイヤー（ビューとビューモデル）を選択して、プレゼンテーションレイヤーにドラッグします。
ほとんどすべての準備ができており、接続のみが欠落しています。 それらを生成するには、レイヤー図のコンテキストメニューを呼び出して、[依存関係の生成]アイテムを選択します。
これで、レイヤーチャートが完成しました。
ViewModelからViewへの矢印について質問がある場合は、 MSDNフォーラムでこのトピックに関する意見を確認するか、ディスカッションに参加してください 。
自動アーキテクチャ制御
さて、最後の瞬間、各ビルドでレイヤー図を自動的に作成する方法は、コードがアーキテクチャと一致することを確認しますか？ 実際には非常に簡単です。 デモのために、ClientApp1で、データアクセスレイヤーに直接アクセスするコンポーネントをViewフォルダーに追加します。
ビルドを起動し、「ビルドが成功しました」を確認します。 アーキテクチャエラーが原因でビルドが失敗するためには、ソリューションエクスプローラーからモデルプロパティを開き（コンテキストメニューまたはF4を選択して押して）、アーキテクチャ検証を有効にする必要があります。
もう一度、構築が開始され、アーキテクチャエラーがあることがわかります。
エラーをダブルクリックして、すぐに松葉杖が詰まっている場所に移動します。
もちろん、依存関係のチェックによりコンパイル時間が長くなるため、開発者が作業する（モデリングプロジェクトを含まない）ソリューションと、同じプロジェクトセットとモデリングプロジェクトを使用してTeam Foundation Serverで自動ビルドする2つのソリューションをビルドできます。 この場合、職場での構築が高速になり、サーバー上でアーキテクチャが監視され、構築エラーにより、バグがすぐに生成されます。
結論に進む前に、小さな発言。 この記事で説明するすべては、Visual Studio 2010とVisual Studio 2012の両方で機能します。必要なものは、UltimateまたはPremiumのバージョンのみです。 Visual Studio 2010の対応するバージョンのライセンスがない場合は、Visual Studio 2012 Ultimateのリリース候補バージョンをここからダウンロードできます 。
結論
1.レイヤーダイアグラムは、新しいプロジェクトで知っておく必要があるツールキットです。
2.アーキテクチャの自動検証により、急いで、または知らないで詰まる「クランチ」の数が減ります。
3.名前空間の適切な命名とArchitecture Explorerの使用により、アーキテクチャを復元する時間を大幅に短縮できます。
追伸この記事で何かについてお話しするのを忘れた場合は、あまり私に誓わず、主な情報源である既存のコードの視覚化を読んでください。