ASP.NET 5上のモジュラーアプリケーション

クライアント向けのWebサイトを開発している間、かなり長い間、私は独自の単純なCMS（Platformus）を使用しました。 ASP.NET + MVCで記述され、ソースコードが閉じられていました。 新しいASP.NET 5の最初のベータ版では、このテクノロジでシステムを書き直してクロスプラットフォームにし、最終的にGitHubに配置することにしました。 この技術は非常に新しいため、この問題に関する情報はほとんどなかったため、偶然またはASP.NET 5自体のソースコードを調査する過程でいくつかの問題の解決策が見つかりました。

簡単にするために、特別なテストソリューションAspNet5ModularAppを準備し、GitHubに投稿しました 。 基本的に、この記事では彼に頼りますが、Platformusで使用したトリックやアイデアの一部にも触れます（部分的には、コメントを受け取ることを期待して）。

主なタスクの決定

CMSの開発に固有の問題を省略した場合、私にとっての主なタスクはプロジェクトの有能なモジュールアーキテクチャでした（そして、まだ残っています）。

メインのWebアプリケーションにはコントローラー、ビュー、またはリソース（スクリプト、スタイル、画像など）を含めるべきではなく、データやそれらの保存方法については知らないが、拡張機能（アセンブリーのセット）については知っておくべきだと判断しました） この場合、彼の唯一のタスクは、すべての拡張機能を見つけてダウンロードし、初期化することです。

同様に、拡張機能は共通のインターフェイスを実装する必要があり、実際には何でも含めることができます。 （ただし、私の場合、ほぼすべての拡張機能がデータを処理するため、このメカニズムを説明する抽象化レベルを追加しました。これにより、すべての拡張機能が統一されたコンテキストでデータを処理できます。これは十分に重要です。これは以下です。）

ほとんどの場合、拡張機能にはコントローラーとビューが含まれている必要があるため、最初にコントローラーとビューを動作させようとしたのは、動的に読み込まれたアセンブリ（つまり、メインWebアプリケーションのproject.jsonで明示的に参照されていないアセンブリ起動後に拡張機能を使用してディレクトリからロードされます）。

コントローラーに問題はありませんでした。 IAssemblyProviderインターフェイスを実装し、DefaultAssemblyProviderからアセンブリをコピーして、拡張ディレクトリから動的にロードされるアセンブリを追加し（ AspNet5ModularApp.ExtensionAssemblyProviderを参照）、新しい実装をConfigureServicesに登録します（ AspNet5ModularApp.Startupを参照）。 唯一のもの：デフォルトでは、MVCはMicrosoft.AspNet.Mvcのようなものを参照するアセンブリ内のコントローラーを探します。 私の場合、ほとんどすべてのプロジェクトがこのアセンブリを参照しているため（これは悪いことですが、なぜこれまでのところそうなったのかを以下で説明します）、すべてのプロジェクトで検索が行われ、確かにパフォーマンスに悪影響を及ぼします。この場合、これを修正する必要があります（もちろん、テストソリューションではパフォーマンスの問題はありません）。

私は少し考えをいじらなければなりませんでした。 私が知る限り、viewsリソースを作成する（たとえば、project.jsonに文字列 "resource"： "Views / **"を追加する）か、ビューの事前コンパイルを使用する（RazorPreCompileModuleから継承したRazorPreCompilationクラスを追加する）ことができます。 この場合、最初に、ネイティブタイプで型付けされた表現を使用できるため、2番目のオプションを好みます（つまり、ビュー自体を含むアセンブリ内で定義されたタイプを意味します-リソースビューの場合、そのようなタイプはGitHub ASP.NETに関する私の質問への回答から理解する限り、この問題も解決できます）、そして、第二に、彼らは単にランタイムでコンパイルを必要としないため、最初のアクセスでより速くロードされます。 さて、ビューのすべてのエラーは、コンパイルの段階ですでに明らかになっています。

テストソリューションAspNet5ModularAppのメインWebアプリケーションは、これらのオプションの両方を同時にサポートします。対応する動作は、AddPrecompiledRazorViewsおよびAddRazorOptions関数を使用して設定されます（ Startup.csを参照）。

プリコンパイルされたビューの操作のために、それらを含むアセンブリをインストールするだけで十分な場合は、リソースビューでIFileProviderインターフェイスを実装し（ AspNet5ModularApp.CompositeFileProviderを参照）、ファイルのソースとしてメインWebアプリケーションを指定する必要があります（デフォルトではこれが当てはまります）ビューを含む動的にロードされるすべてのアセンブリ。 ところで、リソースは表現だけでなく、スクリプト、スタイル、画像などにもなります。 それらを含むアセンブリがCompositeFileProviderに追加された後、それらはアセンブリ内に配置されているパスに沿って使用可能になります。

ExtensionAは最初のオプション（リソースビュー）を示し、ExtensionBは2番目（プリコンパイル済みビュー）を示します。

ここで、解決策がまだ見つかっていないいくつかの問題について話す必要もあります。

まず、ASP.NET 5の異なる部分は異なるバージョンのシステムを使用します*アセンブリ。たとえば、あるプロジェクトでMicrosoft.AspNet.Mvcを接続し、別のプロジェクトでSystem.Runtimeを接続しようとすると、使用されているというエラーが発生します。同じライブラリの異なるバージョン。 現時点では、AspNet5ModularAppはASP.NET 5の8番目のベータ版に基づいて構築されているため、このリリースで修正されると思います。 それまでは、Microsoft.AspNet.Mvcをすべてのプロジェクトに登録しました（Entity Frameworkで動作するプロジェクトを除く-Entity Framework自体で十分です）。同じ依存関係のセットを取得します。 私は同意しますが、これは非常に悪いことですが、些細なことに時間を無駄にしないようにしました。

2番目の（おそらくより深刻な）問題は、拡張機能アセンブリを拡張機能を使用してディレクトリにコピーし、メインのWebアプリケーションが使用しないものをアセンブリが使用する場合、対応する依存関係もそこにコピーする必要があることです。 たとえば、System.Reflection.dllおよびSystem.Reflection.TypeExtensions.dllの拡張子を持つディレクトリに配置する必要がありました（そうでない場合、上記の依存関係を持つアセンブリをロードしようとすると例外が発生します）。 しかし、最悪の部分は、EntityFramework.Sqliteで獲得できるアセンブリのセットを選択できなかったことです。 したがって、メインアプリケーションのproject.jsonにEntityFramework.Sqliteへの明示的なリンクを含める必要がありました（そして、特定の実装は言うまでもなく、データについてまったく知りたくないことを上記で書きました）。 （ちなみに、GACの.dnxにあるアセンブリを登録すればすべて問題ありませんが、これは間違っているようです。）

次に、データとそのストレージを扱い始めました。 拡張機能がさまざまなデータソースで動作し、特定の実装を決定するには、必要なアセンブリを拡張機能のあるディレクトリにコピーするだけで十分でした。

AspNet5ModularApp.Models.Abstractionsプロジェクトでは、モデルの基本インターフェイスであるIEntityを定義しました。 AspNet5ModularApp.Data.Abstractionsプロジェクトでは、 IStorageContext、IStorage、IRepositoryの3つの基本的なインターフェイスを定義しました。 Entity Framework 7を使用してSqliteデータベースを操作するためのこれらのインターフェイスの実装を含むAspNet5ModularApp.Data.EF.Sqliteプロジェクトは、その目的を最もよく示しています。また、このプロジェクトは、拡張機能がモデルを単一のコンテキストに登録できるIModelRegistrarインターフェイスを定義します（参照AspNet5ModularApp.Data.EF.Sqlite.StorageContext.OnModelCreating ）。

一般的な動作原理は次のとおりです。 拡張機能は、複数のプロジェクトで構成できます：コントローラーとビューを含むプロジェクト、モデルを含むプロジェクト、データソースを操作するためのリポジトリの抽象化を含むプロジェクト（各モデルに1つ）、およびこれらの抽象化を実装するプロジェクト（各データソースに1つのプロジェクト）。 コントローラとビューを持つプロジェクトは、リポジトリのモデルと抽象化については知っていますが、特定のデータソースの実装については知りません。 したがって、コントローラーのコンストラクターで、ASP.NET 5 DIビルトインにIStorageのアクセス可能なインスタンスを提供するように要求し、さらに、インターフェイスから特定のリポジトリの利用可能な実装を要求することができます。 （もちろん、組み込みのDIがIStorageのアクセス可能な実装を見つけるために、 AspNet5ModularApp.ExtensionB.ExtensionB.ConfigureServicesで行われていることを通知する必要があります。これを各拡張機能で行わないために、Platformusでは一般的な機能をベアボーンに分けます。 ）

結果

結果として何が起こったのか。 私が書いた依存症の問題に目をつぶると、すぐに解決される可能性が高いので、私の意見では、すべての質問に対する答えを見つけました。 拡張機能を使用してディレクトリにアセンブリをコピーするだけで、アプリケーションの機能を拡張できます。拡張機能には、強く型付けされたビューと、データソースを操作するための単一のコンテキストを含めることができます。 必要に応じて、アプリケーションのプロセスで直接拡張機能を追加および削除できるようにすることは難しくありません。 型検索エンジンにキャッシングを追加することにより、パフォーマンスを大幅に改善することもできます。

私はコメントと発言を喜んでいるだろうし、記事でうまく述べられなかったそれらのポイントを明確にすることも喜んでいるだろう。

リンクと感謝

AspNet5ModularAppへのリンク 。

GitHubユーザーgithub.com/leo9223に感謝します。 このプロジェクトを見せてくれて、私を大いに助けてくれました。 このプロジェクトは、リソースビューを理解するのに役立ちましたが、それでも機能させることはできませんでした。 今、私はすでにその理由を知っています。 拡張機能を持つアセンブリからEmbeddedFileProviderを作成するときに、ベース名前空間がそこに指定されていなかったため、ビューが見つかりませんでした。 ここで手がかりを見つけました。 また、GitHub for ASP.NET開発者に関する私の質問への回答は、彼らの忍耐と注意に感謝しました。