ServiceStackおよび.NET Core

1か月半前、Webサービスとアプリケーションを作成するための人気のあるServiceStackフレームワークがついに.NET Coreのリリースをリリースしました。 このレビューでは、プラットフォームパッケージ自体と、.NET Coreプラットフォームに移植するためにServiceStackを使用してプロジェクトでやり直す必要があるものについて少し説明します。

エントリー

プロジェクトチームが最善を尽くしたとすぐに言う価値があります。 ほぼ1日で、平均的な研究プロジェクトを数十のサービスで新しい現実に適応させることができました。



譲渡からの利益は何ですか？ 間違いなく-客観的に応答とクエリ処理の速度を上げました。 個々の方法により、応答時間は3倍減少しました。 平均して、生産性の伸びは30％でした。 もちろん、主なポイントは、System.Webライブラリ、および一般に、メインのServiceStackプロジェクトのベースであるASP.NETサブシステム全体の不足によりオーバーヘッドが減少したことです。

コアライブラリ

作成者は、メインパッケージで直接.NET Coreをサポートせず、新しいバージョン1.0- *（執筆時点で1.0.25）で個別のパッケージセットをリリースしました。



パッケージのセットは非常に広範囲です：

• ServiceStack.Text.Core
• ServiceStack.Interfaces.Core
• ServiceStack.Client.Core
• ServiceStack.HttpClient.Core
• ServiceStack.Common.Core
• ServiceStack.Redis.Core
• ServiceStack.OrmLite.Core
• ServiceStack.OrmLite.Sqlite.Core
• ServiceStack.OrmLite.SqlServer.Core
• ServiceStack.OrmLite.PostgreSQL.Core
• ServiceStack.Core
• ServiceStack.Mvc.Core
• ServiceStack.Server.Core
• ServiceStack.ProtoBuf.Core
• ServiceStack.Wire.Core
• ServiceStack.Aws.Core
• ServiceStack.RabbitMq.Core
• ServiceStack.Stripe.Core
• ServiceStack.Admin.Core
• ServiceStack.Api.Swagger.Core
• ServiceStack.Kestrel

また、メインプロジェクトと同じコードベースですが、いくつかの点で若干の違いがあります。 おそらく、ほとんどのタスクでは、提示されたパッケージは最小限のコストでコードを移植するのに十分なものになるでしょう。



現在のパッケージのコードは、主観的には98〜99％一致しています。 .netコアインフラストラクチャサポートを必要とする場所には違いがあります。 完全に正確にするために、これらのパッケージは.NET Standart 1.6を完全にサポートしています。 つまり 実際、それらはそれを実装するすべてのプラットフォームで使用できます。 1.6は現在標準の最新バージョンであり、これらはすべて最新のプラットフォームです。 .NET Standard Libraryの詳細をご覧ください。

現在のバージョンの機能

コンテナ

何世紀もの間、ServiceStackは独自のDIコンテナーFunqを使用してきました。 ASP.NETフレームワークは他のものを提供しませんでした。 もちろん、現在のFunqを別のお気に入りのコンテナーに置き換えることもできますが、一般に、 十分な組み込み機能がありました。



Coreバージョンでは、引き続きビルトインFunqを使用できますが、ServiceStackはそれを.NET CoreインフラストラクチャのDIコンテナーに埋め込みます。 実際、2つの場所からコンテナを構成できるようになりました。



メソッドから：

internal class Startup { public void ConfigureServices(IServiceCollection services) { } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プラットフォームが示唆するように、メソッドから：

 internal sealed class ServicesHost : AppHostBase { public override void Configure(Container container) { } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いつものように。 ただし、考慮すべき主な点は、このアプローチでは、サービスの「可視性ゾーン」が表示されることです。 Startupクラスで宣言されたサービスは、アプリケーションのすべてのポイントから有効にできます。 Configureオーバーロード内で設定されるサービスは、ServiceStack内でのみ表示されます。 .NET Coreインフラストラクチャには表示されません。

ロギング

これで、すべてのServiceStackロギングが標準の.NET Coreロガーにプロキシされます。 つまり これで、サードパーティのライブラリを使用してSSログを拡張する必要がなくなりました。 組み込みのLoggerFactoryのロギングを拡張するには、これを使用するだけで十分です 。

ServiceStack.Authentication

なぜなら DotNetOpenAuthは .NET Coreに移植されていないため、この依存関係に関連するすべてが現在機能していません。 私はこの機能を使用していないため、現在どのように「壊れた」かについての詳細は知りません。

SOAP

現在のバージョンで接続されているものはすべて完全にはサポートされていません。

ミニプロファイラー

メインプラットフォーム上で便利な小さなことは、Coreでは機能しません。 System.Webへの依存が必要です。



他の変更およびサポートされている機能とサポートされていない機能については、 こちらをご覧ください 。

移植を開始する場所

プロジェクトを変革します

.NET Coreに移植するには、主に2つの方法があります。



1. project.jsonファイルを追加して、現在のフォルダーをプロジェクトに変換します。これは、ほとんどすべての* .xprojファイル 、 メイン関数を含むファイル 、およびStarupt.csファイル（実際には名前は何でもかまいません）



2.空のASP.NET Coreアプリを作成し、古いプロジェクトからファイルを追加するだけです。



2番目のオプションがより望ましい 現在のプロジェクトを変換および調整するための労力が少し必要です。

へのリンクを追加

標準的なServiceStackパッケージを追加するだけで、何も発明する必要はありません。

 "dependencies": { "Microsoft.AspNetCore.Diagnostics": "1.0.0", "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0", "Microsoft.AspNetCore.Server.Kestrel": "1.0.1", "Microsoft.Extensions.Configuration": "1.0.0", "Microsoft.Extensions.Configuration.FileExtensions": "1.0.0", "Microsoft.Extensions.Configuration.Json": "1.0.0", "Microsoft.Extensions.Configuration.Binder": "1.0.0", "Microsoft.Extensions.Logging.Debug": "1.0.0", "Microsoft.NETCore.App": { "version": "1.0.1", "type": "platform" }, "System.Diagnostics.Tools": "4.0.1", "NLog.Extensions.Logging": "1.0.0-rtm-alpha4", "ServiceStack.Api.Swagger.Core": "1.0.25", "ServiceStack.Client.Core": "1.0.25", "ServiceStack.Common.Core": "1.0.25", "ServiceStack.Core": "1.0.25", "ServiceStack.Interfaces.Core": "1.0.25", "ServiceStack.ProtoBuf.Core": "1.0.25", "ServiceStack.Redis.Core": "1.0.25", "ServiceStack.Text.Core": "1.0.25", "System.Reflection.TypeExtensions": "4.1.0" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

とりわけ、NLogロギングの拡張機能を追加しました。 プロジェクトはそれを以前に使用しました。 構成はnlog.configファイルを介して行われますが、これは古いバージョンと変わりません。

Sturtup.csを変更する

  internal class Startup { private readonly ILoggerFactory _loggerFactory; private readonly ILogger _logger; public Startup(IHostingEnvironment env, ILoggerFactory loggerFactory) { _loggerFactory = loggerFactory; _loggerFactory.AddNLog(); _logger = _loggerFactory.CreateLogger(GetType()); env.ConfigureNLog($"nlog.{env.EnvironmentName}.config"); var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true) .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true) .AddEnvironmentVariables(); Configuration = builder.Build(); } public IConfigurationRoot Configuration { get; } public void ConfigureServices(IServiceCollection services) { OrmLiteConfig.DialectProvider = SqlServer2012Dialect.Provider; services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>(); services.AddSingleton(Configuration); services.AddScoped<IDbConnectionFactory>(p => new OrmLiteConnectionFactory(Configuration.GetConnectionString("DefaultConnection"))); services.AddScoped<IRedisClientsManager>(p => new BasicRedisClientManager(Configuration.GetConnectionString("RedisConnectionString"))); services.AddSingleton<ServicesHost>(); } public void Configure(IApplicationBuilder app, IHostingEnvironment env) { _logger.LogInformation(new EventId(1), "Startup started"); var host = (AppHostBase)app.ApplicationServices.GetService(typeof(ServicesHost)); app.UseServiceStack(host); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はすべてがコンテナにあるアプローチを使用しているため、メインのServicesHostクラスもコンテナに配置されます。 これにより、後のコンストラクターで、独立した解決に頼ることなく、必要な依存関係を取得できます。



以前は、多くのプロジェクトがSystem.Webスペースのシングルトンを使用して現在のHttpコンテキストにアクセスしていました。 現在、このクラスは.Net Coreでは使用できません。次のサービスを使用する必要があります。

 services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、外部からの要求がある場合にのみ、 HttpContextAccessor.HttpContextの値がnullと異なることを知る必要があります。 それ以外の場合、常にnullが含まれます 。



構成ファイルの接続方法は、 appsettingsだけでなく 、 nlog構成などの他の行にも使用できます。

 env.ConfigureNLog($"nlog.{env.EnvironmentName}.config");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メインコンテナでは、プロジェクト内のすべての依存関係（データアクセスレイヤー、外部サービスなど）も構成されます。 ServiceStack内には、SSの外部の誰も使用しない非常に限られた数だけを残す必要があります。

サービスホストの変更

これは、ServiceStack環境を構成するための主要なコンテナークラスであり、通常は既に古いプロジェクトにあります。 各プロジェクトでは異なる方法で呼び出すことができますが、本質は、このクラスがAppHostBaseクラスから継承されることです。これがポータブルプロジェクトの場合ではない場合、このクラスから継承する必要があります。

 internal sealed class ServicesHost : AppHostBase { private readonly IHttpContextAccessor _accessor; private readonly IAppSettings _settings; private readonly ILogFactory _loggerFactory; private readonly IRedisClientsManager _redisClientsManager; public ServicesHost(IHttpContextAccessor accessor, IAppSettings settings, ILogFactory loggerFactory, IRedisClientsManager redisClientsManager): base(StringsConstants.SERVICES_NAME, typeof(AuthService).GetAssembly()) { _accessor = accessor; _settings = settings; _loggerFactory = loggerFactory; _redisClientsManager = redisClientsManager; } public override void Configure(Container container) { //    ConfigurePlugins(); container.RegisterValidators(typeof(RegistrationRequestValidator).GetAssembly()); ConfigureBinders(); //      ConfigureGlobalRequestFilters(); //     SetConfig(new HostConfig { ApiVersion = StringsConstants.API_VERSION, #if !DEBUG EnableFeatures = Feature.Json | Feature.ProtoBuf | Feature.Html, WriteErrorsToResponse = false, #else EnableFeatures = Feature.Html | Feature.Json | Feature.RequestInfo | Feature.Metadata | Feature.ProtoBuf, WriteErrorsToResponse = true, #endif DebugMode = _settings.Get("DebugMode", false), LogFactory = _loggerFactory, Return204NoContentForEmptyResponse = true, DefaultRedirectPath = "/swagger-ui/", MapExceptionToStatusCode = { {typeof(DomainException), (int) HttpStatusCode.InternalServerError} } }); } ..... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の場合、標準のクエリ検証機能はServiceStack内で構成されています。 さらに、どこでも使用されていません。



このファイルを.NET Coreに移植する複雑さは、プロジェクトによって異なります。 標準のSS機能と、.NET Coreに既に移植されている他のサードパーティパッケージのみを使用する場合、ファイルの変更は最小限で済みます。

System.configuration

これは、従来のASP.NETから.NET Coreに移植する際の最も「痛い」場所の1つです。 ServiceAppは、 IAppSettings抽象化の実装で、古いapp / web.configファイルを使用して作業を使用します。 彼にappsettings.configを操作する機会を与えるには、 IAppSettingsのバージョンを実装するだけです。 このクラスは実際には非常に単純で、ServiceStack自体のインフラストラクチャの一部を使用します。

  public class AppSettings : AppSettingsBase { public AppSettings (IConfigurationRoot root, string tier = null) : base(new ConfigurationManagerWrapper(root)) { Tier = tier; } public override string GetString(string name) { return GetNullableString(name); } private class ConfigurationManagerWrapper : ISettings { private readonly IConfigurationRoot _root; private Dictionary<string, string> _appSettings; public ConfigurationManagerWrapper(IConfigurationRoot root) { _root = root; } private Dictionary<string, string> GetAppSettingsMap() { if (_appSettings == null) { var dictionary = new Dictionary<string, string>(); var appSettingsSection = _root.GetSection("appSettings"); if (appSettingsSection != null) { foreach (var child in appSettingsSection.GetChildren()) { dictionary.Add(child.Key, child.Value); } } _appSettings = dictionary; } return _appSettings; } #region Implementation of ISettings public string Get(string key) { string str; if (!GetAppSettingsMap().TryGetValue(key, out str)) return null; return str; } public List<string> GetAllKeys() { return GetAppSettingsMap().Keys.ToList(); } #endregion } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテナに依存関係を追加してください：

 services.AddSingleton<IAppSettings, AppSettings>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それだけです-あなたのポケットにあるappsettings.configファイルのappSettingsセクションの設定。

おわりに

上記で説明したのは、すべて（！）の変更（一部のインターフェイスの名前を変更して他のクラスに転送することは簡単なことです）をServiceStackのフルバージョンで書かれたプロジェクトに追加して、Coreバージョンで動作するようにしました。



OrmLite、Redis、Text、Client、およびその他の便利なパッケージに関するすべては、変更を一切必要としませんでした。 また、たとえば、EFと同じOrmLiteを非常に有利に区別します。 EFで記述されたプロジェクトを完全な.NETから.Coreに移植するには、多くの労力を費やす必要があります。 すぐに操作はまったく必要ありません-すべてが機能します。



完全な.NETのプロジェクトでServiceStackを使用した場合、.NET Coreへの切り替えにはかなり時間がかかる場合があります。 SSチームは、すべてを可能な限り互換性のあるものにしようとしましたが、完全に可能でした。 もちろん、ServiceStackは有料ですが、個人的な目的でオープンソースプロジェクトを使用することを禁止するものはありません。



そして、小さなライフハックの終わりに、開発中の使用に関する制限を削除する方法（決して十分ではない）：



1. github.com/ServiceStack/ServiceStack.Textをダウンロードします

2. LicenseUtils.csファイルの制限を変更するか 、チェック呼び出しを無効にします

3. Coreプロジェクトをまとめる

4.ファイルをbin \ Release \ netstandart1.3から％HOME％\。Nuget \ packages \ ServiceStack.Text.Core \ {ご使用のバージョン} \ lib \ netstandart1.3にコピーします

5.利益！



新しいバージョンが表示された場合は、すべての手順を再度実行する必要があります。 キャッシュ全体を削除するまで恐れる必要はありません。「自分の」アセンブリは消去されません。



PS：そうそう...今ではすべてがIISではなく、Dockerコンテナで動作します。



UPD：コメントで、 Scratchは制限を回避するためのより侵襲性の低いオプションを提案しましたが、Coreバージョンでは若干異なります：

 public static class ServiceStackHelper { static ServiceStackHelper() { var instance = new MyNetStandardPclExport(); PclExport.Instance = instance; NetStandardPclExport.Provider = instance; Licensing.RegisterLicense(string.Empty); } public static void Help() { } private class MyNetStandardPclExport: NetStandardPclExport { public override LicenseKey VerifyLicenseKeyText(string licenseKeyText) { return new LicenseKey { Expiry = DateTime.MaxValue, Hash = string.Empty, Name = "Habr", Ref = "1", Type = LicenseType.Enterprise }; } } }