ASP.NET vNext チュートリアルによると:vNext is host agnostic . You can host your app in IIS, or self-host in a custom process
現在のasp.netホストと新しいホストの違いを示して、これを深く理解するのを手伝ってくれる人はいますか?
ASP.NET vNext チュートリアルによると:vNext is host agnostic . You can host your app in IIS, or self-host in a custom process
現在のasp.netホストと新しいホストの違いを示して、これを深く理解するのを手伝ってくれる人はいますか?
2002 年には、基本的に .NET プラットフォーム用の Web サーバーは 1 つだけでした。それが IIS でした。数年後、Visual Studio Development Web Server ("Cassini"、元の Web Matrix の一部) が開発専用サーバーとして登場しました。しかし、最終的にこれらはすべて、アプリケーションと Web サーバーの間のホスティング レイヤーとして System.Web を使用しました。System.Web ホストは IIS と緊密に結合されているため、他のホストで実行するのは非常に困難です。VS Dev Web サーバーでの実装でさえ、特定の機能しかサポートしていなかったため、制限がありました。そのため、System.Web に依存する典型的な ASP.NET アプリケーション用の運用品質の "ホスト" は 1 つだけでした。
約 10 年後、OWINはアプリケーションと Web サーバー間のインターフェイスとして登場しました。これにより、OWIN 互換のアプリケーションは、OWIN を介して、OWIN 互換のホスティング レイヤーを持つ Web サーバーと通信できるようになりました。Microsoft は、ASP.NET Web API、ASP.NET SignalR、および IIS (および IIS Express)、Katana のセルフホスト サーバー、カスタム ホスト(つまり、カスタム アプリで Katana のホストを実行します)。Katana と同じアプリを実行できるNowinという別の OWIN 実装があります。これは、ホスト不可知論の例です。
さらに数年早送りすると、 ASP.NET vNextが登場します。これは、ミドルウェアを持ち、ホストに依存しないという点で、OWIN と非常によく似たモデルに従います。ASP.NET vNext には、OWIN ミドルウェア アプリ コンポーネント用の互換性レイヤーもあります。
ASP.NET vNext は、Katana や OWIN と同じようにホストに依存しません。IApplicationBuilder
ASP.NET vNext を使用して作成されたアプリケーションは、 (以前のIBuilder
) インターフェイスなどのホスト抽象化レイヤーについてのみ認識します。アプリケーションは Web サーバーと直接通信しません。この抽象化の多くは「機能インターフェース」を介して行われるため、一部のサーバーは機能を実装でき、他のサーバーは実装しないことを選択できます。
ASP.NET vNext アプリケーションは、IIS、IIS Express、独自のカスタム EXE、新しいクロスプラットフォームKestrelサーバーでホストできます。将来的にはさらに多くのホストがホストされることは間違いありません。
Katana も ASP.NET vNext も、IIS やその他のホストに代わるものではありませんが、どちらにも代替 Web サーバーがあります。IIS は、Katana や ASP.NET vNext と比較して、アプリケーションのウォームアップ、豊富なアプリケーション ライフタイム管理 (つまり、アプリがクラッシュした場合の対処方法、使用するメモリ量の制御、その他の種類のスロットリング) など、より高度な機能をサポートしています。 、リモート管理など。
私は OWIN のメンバーではなかったので、OWIN を作成した動機について話すことはできません。しかし、Web サーバーのホストを抽象化するメリットは数多くあります。
ASP.NET vNext の動機の一部は、ASP.NET vNext の公式サイトの入門チュートリアルにリストされています。簡単にまとめると、Web アプリとサービスを構築するための、クロスプラットフォーム、オープンソース、サイドバイサイド、従量制、ホストに依存しないプラットフォームを用意することです。マーケティングのように聞こえますが、これらはすべてシステムの重要な側面です。NodeJS はこれとまったく同じ一連の機能を提供しますが、もちろん詳細を見ると、多くの実装の違いがあり、間違いなくいくつかのより深い哲学的な違いもあります。これらの機能をサポートする動機は、一般的に一目瞭然です。
これは、ASP.NET Web フォームから MVC、Web API、SignalR、Katana、ASP.NET vNext までのすべてを含む、一般的な ASP.NET の対象者に関するものであることに注意してください。これらのフレームワークはいずれも、あらゆる規模のプロジェクトに適しており、ある程度のスキルを持つ開発者なら誰でも使用できるはずです。これは、それらを使用するプロジェクトのサイズを見ると明らかです。このサイト (StackOverflow.com) の一部は、ASP.NET MVC を使用して非常に高度な開発者によって構築されています (私は推測します)。ASP.NET vNext は、これらの同じフレームワークのほとんどの将来のバージョンであり、同じ種類のアプリケーションと同じ種類の開発者を対象としています。
ASP.NET vNext と OWIN の詳細については、いずれかの開発者のブログ投稿をご覧ください: http://whereslou.com/2014/06/10/asp-net-vnext-moving-parts-owin/
vNext は依然として非常に明るい色の高速移動オブジェクトであることを念頭に置いてください。現状では、ホストに依存しない「半分」のようなものです。
それが定義して適用するミドルウェア仕様は、プログラムを配置するための非常に一般的なインターフェースを可能にします。したがって、開発方法は同じです。しかし、vNext アプリはそれ自体がサーバーであり、奇妙なことに現在、使用しているサーバーの種類に応じたグルー ライブラリを含める必要があります。
これは、ファイル内で使用するサーバーのタイプを指定する必要があることを確認することで確認project.json
できます。vNext プロジェクトが本当に不可知論的である場合、システム レベルでサーバーを選択し、選択したサーバーからアプリを指定、マウント、または起動します。
ライフサイクルが関係しているため、やや複雑です。ここでの説明が終わったら、vNext プロジェクトのこの github の問題に進むことをお勧めします。