ASP.NETからASP.NET Core 2.0への移行

この記事は、ASP.NETからASP.NET Core 2.0にアプリケーションを移植するためのリファレンスガイドの翻訳です。 オリジナルへのリンク







内容



  1. 必要条件
  2. フレームワークの選択
  3. プロジェクト構造の違い
  4. Global.asaxの置き換え
  5. 構成ストレージ
  6. 組み込みの依存性注入
  7. 静的ファイルを操作する


必要条件



•.NET Core 2.0.0 SDK以降。







フレームワークの選択



ASP.NET Core 2.0プロジェクトを使用するには、開発者は.NET Coreまたは.NET Frameworkを使用するか、両方のオプションを同時に使用するかを選択する必要があります。 追加情報については、 サーバーアプリの.NET Coreと.NET Frameworkの選択ガイド(要するに、.NET Coreは.NET Frameworkとは異なり、クロスプラットフォームライブラリであると言えます)を使用して、どのFrameworkが最も望ましいかを理解できます。 。

プロジェクトで必要なフレームワークを選択した後、NuGetパッケージへのリンクを指定する必要があります。

.NET Coreを使用すると、 統合された ASP.NET Core 2.0 パッケージ (メタパッケージ)のおかげで、多数の明示的なパッケージ参照がなくなります。 これにより、プロジェクトへのMicrosoft.AspNetCore.All



メタパッケージのインストールは次のようになります。







 <ItemGroup> <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" /> </ItemGroup>
      
      





プロジェクト構造の違い



.csprojプロジェクトファイルの構造は、ASP.NET Coreで簡素化されています。 重要な変更点は次のとおりです。







•ファイルをプロジェクトに追加する場合、ファイルを明示的に指定することはオプションです。 したがって、大規模なチームがプロジェクトに取り組んでいる場合、XMLマージ中の競合のリスクが軽減されます。

•他のプロジェクトへのGUIDリンクがなくなり、読みやすさが向上します。

•Visual Studioからダウンロードせずにファイルを編集できます。











Global.asaxの置き換え



ASP.NETアプリケーションのエントリポイントは、Global.asaxファイルです。 ルート構成やフィルターやエリアの登録などのタスクは、Global.asaxファイルで処理されます







 public class MvcApplication : System.Web.HttpApplication { protected void Application_Start() { AreaRegistration.RegisterAllAreas(); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); BundleConfig.RegisterBundles(BundleTable.Bundles); } }
      
      





このアプローチは、アプリケーションとアプリケーションがデプロイされているサーバーを密接に接続します。 接続性を減らすために、複数のフレームワークを一緒に共有するためのより正確な方法を提供する手段としてOWINが導入されました。

OWINでは、必要なモジュールのみをクエリパイプラインに追加できます。 ランタイムは、 スタートアップを使用してサービスと要求パイプラインを構成します。







Startup



は、アプリケーションとともにミドルウェアサービスのセットを登録します。 リクエストごとに、アプリケーションは中間サービスの各セットを呼び出します。中間サービスは、ハンドラーのリンクリストの最初の要素へのポインターを持っています。







中間サービスの各コンポーネントは、1つ以上のハンドラーをリクエスト処理パイプラインに追加できます。 これは、リストの一番上にあるハンドラーへの参照を返すことにより行われます。







そして、ハンドラーは、作業を終了すると、キューから次のハンドラーを呼び出します。

ASP.NET Coreでは、アプリケーションのエントリポイントはStartup



クラスであり、Global.asaxへの依存関係を中和します。







.NET Frameworkが最初に選択された場合、OWINを使用して、次の例のようにクエリパイプラインを構成できます。







 using Owin; using System.Web.Http; namespace WebApi { // :         OWIN.       ,  appSetting owin: AutomaticAppStartup   «false». //         OWIN    ,     global.asax   MapOwinPath   MapOwinRoute  RouteTable.Routes public class Startup { //         . public void Configuration(IAppBuilder builder) { HttpConfiguration config = new HttpConfiguration(); //    , config.Routes.MapHttpRoute("Default", "{controller}/{customerID}", new { controller = "Customer", customerID = RouteParameter.Optional }); //           xml  json config.Formatters.XmlFormatter.UseXmlSerializer = true; config.Formatters.Remove(config.Formatters.JsonFormatter); // config.Formatters.JsonFormatter.UseDataContractJsonSerializer = true; builder.UseWebApi(config); } } }
      
      





また、必要に応じて、他の中間サービスをこのパイプラインに追加できます(ロードサービス、構成設定、静的ファイルなど)。

.NET Coreフレームワークのバージョンに関しては、同様のアプローチがここで使用されますが、エントリポイントを決定するためにOWINを使用しない限りではありません。 別の方法として、 Main



メソッドがProgram.csで使用され(コンソールアプリケーションと同様)、 Startup



がロードされます:







 using Microsoft.AspNetCore; using Microsoft.AspNetCore.Hosting; namespace WebApplication2 { public class Program { public static void Main(string[] args) { BuildWebHost(args).Run(); } public static IWebHost BuildWebHost(string[] args) => WebHost.CreateDefaultBuilder(args) .UseStartup<Startup>() .Build(); } }
      
      





スタートアップにはConfigureメソッドが含まれている必要があります。 Configureは、リクエストパイプラインで使用されるサービスを定義します。 次の例(標準のWebサイトテンプレートから取得)では、いくつかの拡張メソッドを使用して、サポート付きのパイプラインを構成しています。

•BrowserLink

•エラーページ

•静的ファイル

•ASP.NET Core MVC

•アイデンティティ







 public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { loggerFactory.AddConsole(Configuration.GetSection("Logging")); loggerFactory.AddDebug(); if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); app.UseDatabaseErrorPage(); app.UseBrowserLink(); } else { app.UseExceptionHandler("/Home/Error"); } app.UseStaticFiles(); app.UseIdentity(); app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); }); }
      
      





その結果、ランタイムとアプリケーションが分離され、将​​来的に別のプラットフォームに移行する機会が与えられます。

注: ASP.NET Coreのスタートアップとミドルウェアをより深く理解するには、ASP.NET Coreでスタートアップを学習できます。







構成保管



ASP.NETは設定の保存をサポートしています。 たとえば、これらはアプリケーションがデプロイされたランタイムで使用される設定です。 アプローチ自体は、カスタムキーと値のペアを保存するために、 Web.configファイルの<appSettings>



セクションが使用されるというものでした。







 <appSettings> <add key="UserName" value="User" /> <add key="Password" value="Password" /> </appSettings>
      
      





アプリケーションは、System.Configuration名前空間のConfigurationManager.AppSettingsコレクションを使用してこれらの設定にアクセスしました。







 string userName = System.Web.Configuration.ConfigurationManager.AppSettings["UserName"]; string password = System.Web.Configuration.ConfigurationManager.AppSettings["Password"];
      
      





ASP.NET Coreでは、アプリケーションの構成データを任意のファイルに保存し、読み込みの初期段階でサービスを使用して読み込むことができます。

新しいテンプレートプロジェクトappsettings.jsonでデフォルトで使用されるファイル:







 { "Logging": { "IncludeScopes": false, "LogLevel": { "Default": "Debug", "System": "Information", "Microsoft": "Information" } }, //      .   JSON,      :  //   ,    "AppConfiguration": { "UserName": "UserName", "Password": "Password" } }
      
      





IConfiguration



、このファイルをアプリケーションのIConfiguration



インスタンスにダウンロードします。







 public Startup(IConfiguration configuration) { Configuration = configuration; } public IConfiguration Configuration { get; }
      
      





そして、これはアプリケーションがこれらの設定を取得するために構成を使用する方法です。







 string userName = Configuration.GetSection("AppConfiguration")["UserName"]; string password = Configuration.GetSection("AppConfiguration")["Password"];
      
      





Dependency Injection(DI)など、プロセスの信頼性を高めるこのアプローチに基づく他の方法があります。

DIアプローチは、強く型付けされた構成オブジェクトのセットへのアクセスを提供します。







 // , AppConfiguration -  ,       AppConfiguration services.Configure<AppConfiguration>(Configuration.GetSection("AppConfiguration"));
      
      





注: ASP.NET Coreの構成をより深く理解するには、ASP.NET Coreの構成に精通してください。







組み込みの依存性注入



大規模でスケーラブルなアプリケーションを作成する際の重要な目標は、コンポーネントとサービス間の接続を緩めることです。 依存性注入は、この問題を解決するための一般的な手法であり、その実装はASP.NET Coreに組み込まれたコンポーネントです。

ASP.NETアプリケーションでは、開発者はサードパーティのライブラリを使用して注入依存関係を実装しました。 そのようなライブラリの例はUnityです。

Unityで依存性注入を設定する例は、 UnityContainer



ラップされたIDependencyResolver



実装です。







 using Microsoft.Practices.Unity; using System; using System.Collections.Generic; using System.Web.Http.Dependencies; public class UnityResolver : IDependencyResolver { protected IUnityContainer container; public UnityResolver(IUnityContainer container) { if (container == null) { throw new ArgumentNullException("container"); } this.container = container; } public object GetService(Type serviceType) { try { return container.Resolve(serviceType); } catch (ResolutionFailedException) { return null; } } public IEnumerable<object> GetServices(Type serviceType) { try { return container.ResolveAll(serviceType); } catch (ResolutionFailedException) { return new List<object>(); } } public IDependencyScope BeginScope() { var child = container.CreateChildContainer(); return new UnityResolver(child); } public void Dispose() { Dispose(true); } protected virtual void Dispose(bool disposing) { container.Dispose(); } }
      
      





UnityContainer



インスタンスを作成し、サービスを登録して、 UnityContainer



の依存関係の解決をHttpConfiguration



の新しいUnityResolver



インスタンスに設定します。







 public static void Register(HttpConfiguration config) { var container = new UnityContainer(); container.RegisterType<IProductRepository, ProductRepository>(new HierarchicalLifetimeManager()); config.DependencyResolver = new UnityResolver(container); //     }
      
      





次に、必要に応じてIProductRepository



を注入しIProductRepository









 public class ProductsController : ApiController { private IProductRepository _repository; public ProductsController(IProductRepository repository) { _repository = repository; } }
      
      





依存性注入はASP.NET Coreの一部であるため、Startup.cs内のConfigureServices



メソッドにサービスを追加できます。







 public void ConfigureServices(IServiceCollection services) { //   services.AddTransient<IProductRepository, ProductRepository>(); }
      
      





そして、Unityの場合のように、リポジトリインジェクションはどこでも実行できます。

注:詳細は、ASP.NET CoreのDependency Injectionにあります。







静的ファイルを操作する



Web開発の重要な部分は、静的機能を提供する機能です。 静的の最も一般的な例は、HTML、CSS、JavaScript、および画像です。

これらのファイルは、後で参照によりアクセスできるように、アプリケーションの共有フォルダー(またはCDNなど)に保存する必要があります。 ASP.NET Coreでは、静的を扱うアプローチが変更されました。







ASP.NETでは、静的変数は異なるディレクトリに保存されます。

また、ASP.NET Coreでは、静的ファイルはデフォルトで「Webルート」(/ wwwroot)に保存されます。 これらのファイルへのアクセスは、 UseStaticFiles



拡張UseStaticFiles



を使用して行われます。





 public void Configure(IApplicationBuilder app) { app.UseStaticFiles(); }
      
      





たとえば、 wwwroot / imagesフォルダーにある画像は、ブラウザーのhttp://<app-address>/images/<imageFileName>



から利用できます。

注: .NET Frameworkを選択した場合、さらにMicrosoft.AspNetCore.StaticFiles



NuGetパッケージをインストールする必要があります。

注: ASP.NET Coreでの静的ファイルの提供に関する詳細なリファレンスについては、ASP.NET Core での静的ファイルの操作の概要を参照してください。







翻訳されたpoledustaren








All Articles