WCFの本当に透過的な使用

やる気

デスクトップの世界にとって、wcfは、ローカルネットワークとグローバルネットワークの両方で.netでクライアントとサーバーの対話を整理する最も一般的な方法です。 構成が柔軟で、使いやすく、透過的です。



少なくともそうすべきです。 実際には、新しいサービスの追加は日常的な作業です。 サーバーで構成を登録することを忘れないでください。クライアントで同じことを行い、プロキシクラスを作成または生成する必要があります。 構成の維持は不便です。 サービスが変更された場合は、プロキシクラスを変更する必要があります。 また、IoCコンテナーに登録することを忘れないでください。 そして、新しいサービス用の新しいホストを追加します。 また、単純な非同期性も必要です。 それとは別に、すべてがシンプルですが、このリストをすでに3回追加した記事でも、何も見逃していないかどうかはわかりません。



自動化する時間。 ソリューションの作成からwcfサービスの呼び出しまでの最も単純なシナリオは、次のようになります。

1. インストールパッケージRikrop.Core.Wcf.Unity
2. ServiceContractとその実装を作成します
3. サーバーとクライアントで、IoCに1行の登録を追加します（構成を編集する必要はありません）
4. 2行からホストを上げる
   
   

   var assembly = Assembly.GetExecutingAssembly(); _serviceHostManager.StartServices(assembly);
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

5. クライアントで、IServiceExecutor <TService>を解決します。 このラッパーは、サービスのメソッドを呼び出すのに役立ち、チャネルでの作業を隠します。
6. 使用できます

    var articles = await _myServiceExecutor.Execute(service => service.GetArticles());
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

クイックスタート

クライアント/サーバーアプリケーションを作成します。 クライアントは、数値のインデックスをフィボナッチ数列からサーバーに渡し、サーバーは指定されたインデックスを持つ数列をシーケンスから返します。 ロギングとエラー処理は記事のコードから削除されましたが、 githubのコードでは全体的なアプローチを説明するより完全な例を示します。

現実に近いプロジェクト構造：







Server.Contractsには、wcfサービスのインターフェイス、Server-それらの実装、およびhoster-wcfサービスを発生させるクラスの実装が含まれています。 BL-サーバーロジック。 ConsoleServiceHostは、コンソールアプリケーションドメインでサービスをホストします。 Client.Presentaionには、対応するクライアント層が含まれています。 この例では、サービス呼び出しコマンドと結果の処理のみがあります。 クライアントは、以前のアセンブリを使用してユーザー入力を処理するコンソールアプリケーションです。



実際には、nugetパッケージは次のようにインストールする必要があります。

• Rikrop.Core.Wcf.Unityには、wcfが機能するために必要なインフラストラクチャをIoCコンテナーに登録するためのヘルパーが含まれています。 これは、対話のあらゆる側面を迅速にカスタマイズするためのターンキーソリューションと拡張機能のセットです。 パッケージは、IoCコンテナーにサーバーとクライアントの登録があるプロジェクトに追加する必要があります。 このRikropWcfExample.ServerとRikropWcfExample.Clientがあります。
• Rikrop.Core.Wcfには、wcf、チャネル管理、セッション、認証、wcfサービスのホスティングを操作するためのメインクラスが含まれています。 これをRikropWcfExample.Serverに追加すると、ホストとRikropWcfExample.Client.Presentation *があり、そこからwcfサービスが呼び出されます。

RikropWcfExample.Server.Contractsで、 wcfサービスの説明を追加します 。

 using System.ServiceModel; using System.Threading.Tasks; namespace RikropWcfExample.Server.Contracts { [ServiceContract] public interface ICalculatorService { [OperationContract] Task<ulong> GetFibonacciNumber(int n); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CalculatorService.csの実装は、リクエストを渡し、ビジネスロジックレイヤーから結果を返します。

 using RikropWcfExample.Server.BL; using RikropWcfExample.Server.Contracts; using System.Threading.Tasks; namespace RikropWcfExample.Server { public class CalculatorService : ICalculatorService { private readonly FibonacciCalculator _fibonacciCalculator; public CalculatorService(FibonacciCalculator.ICtor fibonacciCalculatorCtor) { _fibonacciCalculator = fibonacciCalculatorCtor.Create(); } public async Task<ulong> GetFibonacciNumber(int n) { return await _fibonacciCalculator.Calculate(n); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

今のところ、注意すべき点の1つは、wcfサービスが非同期を記述するためにasync / awaitを使用していることです。 それ以外の場合、特定のデザインはありません。



それでは、登録に移りましょう。 サーバーの最も単純な構文は、バインディングのタイプ（NetTcp）にサービスに追加する必要がある動作のリストを示します。

 private static IUnityContainer RegisterWcfHosting(this IUnityContainer container, string serviceIp, int servicePort) { container .RegisterServerWcf( o => o.RegisterServiceConnection(reg => reg.NetTcp(serviceIp, servicePort)) .RegisterServiceHostFactory(reg => reg.WithBehaviors().AddDependencyInjectionBehavior()) ); return container; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントの場合、サービスのラッパーエグゼキューターのタイプ（ServiceExecutor）、バインディングのラッパーのタイプ（StandartはNetTcpを想定）、実際にはサーバーアドレスが示されます：

 private static IUnityContainer RegisterWcf(this IUnityContainer container, string serviceIp, int servicePort) { container .RegisterClientWcf(o => o.RegisterServiceExecutor(reg => reg.Standard() .WithExceptionConverters() .AddFaultToBusinessConverter()) .RegisterChannelWrapperFactory(reg => reg.Standard()) .RegisterServiceConnection(reg => reg.NetTcp(serviceIp, servicePort))); return container; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それだけです インターフェイスごとに各サービスを登録する必要はありません。プロキシを作成する必要も、構成にwcfを登録する必要もありません。これらの登録により、あたかもローカルコールのようにサービスの操作をすぐに開始できます。

ただし、最初にサーバーでホストする必要があります。 Rikrop.Core.WcfライブラリにはすでにServiceHostManagerクラスが含まれており、これはすべての作業を独自に実行します。 各サービスを登録する必要はありません。

 using Rikrop.Core.Wcf; using System.Reflection; namespace RikropWcfExample.Server { public class WcfHoster { private readonly ServiceHostManager _serviceHostManager; public WcfHoster(ServiceHostManager serviceHostManager) { _serviceHostManager = serviceHostManager; } public void Start() { var assembly = Assembly.GetExecutingAssembly(); _serviceHostManager.StartServices(assembly); } public void Stop() { _serviceHostManager.StopServices(); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバーを起動しましょう：

 public static void Main() { using (var serverContainer = new UnityContainer()) { serverContainer.RegisterServerDependencies(); var service = serverContainer.Resolve<WcfHoster>(); service.Start(); Console.WriteLine(" .    Enter."); Console.ReadLine(); service.Stop(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアントを実行します 。

 static void Main() { using (var container = new UnityContainer()) { container.RegisterClientDependencies(); var calculateFibonacciCommandCtor = container.Resolve<CalculateFibonacciCommand.ICtor>(); int number; while (int.TryParse(GetUserInput(), out number)) { var command = calculateFibonacciCommandCtor.Create(); var result = command.Execute(number); Console.WriteLine("Fibonacci[{0}] = {1}", number, result); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

動作します：

従来のアプローチおよび拡張性との比較

提案されたソリューションは、非常に多くのインフラストラクチャコードを必要とし、通常のwcfの使用に比べて利点がないように思われるかもしれません。 プロジェクトの作業中に発生する典型的な状況の例によって違いを示すのが最も簡単です。

既存のwcfサービスへの新しいメソッドの追加、または既存のメソッドの署名の変更

Rikrop.Core.Wcf（.Unity）	ライブラリを使用せずに
メソッド定義をServiceContractに追加します。 wcfサービスのクラスに実装を追加します。 これで、クライアントで新しいメソッドを呼び出すことができます。	メソッド定義をServiceContractに追加します。 wcfサービスのクラスに実装を追加します。 クライアントでプロキシクラスを生成するか、クライアントで新しいサービスを呼び出す手動実装を追加します（プロキシクラスを直接使用しない場合は、両方のオプションがあります。 これで、クライアントで新しいサービスを呼び出すことができます。

既存のホストに新しいwcfサービスを追加する

Rikrop.Core.Wcf（.Unity）	ライブラリを使用せずに
新しいサービスのServiceContractを作成します。 サービス契約を実装します。 これで、クライアントで新しいサービスを呼び出すことができます。	新しいサービスのServiceContractを作成します。 サービス契約を実装します。 クライアントでプロキシクラスを生成するか、クライアントで新しいサービスを呼び出す手動実装を追加します（プロキシクラスを直接使用しない場合は、両方のオプションがあります。 新しいサービスのServiceHostを初期化するwcfホストコードに追加します。 新しいサービスのプロキシクラスをクライアントIoCコンテナーに登録します。 クライアントではなくサーバーにサービス構成を追加します。 これで、クライアントで新しいサービスを呼び出すことができます。

すべてのwcfサービスの設定を変更する（例としてバインディングタイプを使用）

Rikrop.Core.Wcf（.Unity）	ライブラリを使用せずに
サーバー登録で、バインディングタイプ*の行を変更します。 クライアント登録で、タイプバインディングタイプ*の行を変更します。 *パブリックの結果を参照カスタム <TServiceConnection>（LifetimeManager lifetimeManager = null、params InjectionMember [] injectionMembers）ここで、TServiceConnection：IServiceConnection	app.configサーバーで、<bindings> *ブロックのすべてのエントリを変更します。 クライアントapp.configで、<bindings> *ブロックのすべてのエントリを変更します。 *作業量はwcfサービスの数に比例します。 それらが100個ある場合、迅速なファイル置換が機能することのみを期待できます。

複数のwcfサービスの設定の変更（バインディングタイプを例として使用）

Rikrop.Core.Wcf（.Unity）	ライブラリを使用せずに
サーバーで、新しいアドレスとバインディングのタイプの登録を追加します。 クライアント登録で、異なるアドレスとバインディングの種類の新しい登録を追加します。	サーバーのapp.configで、目的のwcfサービスの<bindings>ブロックのエントリを変更します。 クライアントapp.configで、目的のwcfサービスの<bindings>ブロックのエントリを変更します。

最後の2つのポイントについていくつかの言葉を言う価値があります。 app.configが適切に構成されていれば、変更を加えるのはとても簡単です。 これは、アプリケーションを再構築せずに実行できます。 実際の開発では、wcf構造化構成は非常にまれであり、これは反復的な開発によるものです。 また、初期設定が要件を満たしている場合、プログラマー以外のユーザーも構成を頻繁に変更する必要があります。 同時に、コンパイラが見つけられないようなタイプミスをすることは簡単です。

拡張性。 セッションの認可および動作の動作

登録時の動作の追加により、機能の拡張と動作の変更が発生します。 最も一般的なアプリケーションは、wcfメッセージのヘッダーでセッション情報を送信する動作です。

機能を示すために、前の例の拡張コードを使用して別のブランチを作成しました。 標準の動作設定では、開発者は承認方法を選択するように求められます-これはOperationContractです。これは、メッセージヘッダーにセッションのないユーザーが使用できます。 他のメソッドの呼び出しは、入力されたヘッダーでのみ可能です。



サーバーでの登録は次のようになります。

 container .RegisterType<ISessionResolver<Session>, SessionResolver<Session>>() .RegisterServerWcf( o => o.RegisterServiceConnection(reg => reg.NetTcp(serviceIp, servicePort)) .RegisterServiceHostFactory(reg => reg.WithBehaviors() .AddErrorHandlersBehavior(eReg => eReg.AddBusinessErrorHandler().AddLoggingErrorHandler(NLogger.CreateEventLogTarget())) .AddDependencyInjectionBehavior() .AddServiceAuthorizationBehavior(sReg => sReg.WithStandardAuthorizationManager() .WithStandardSessionHeaderInfo("ExampleNamespace", "SessionId") .WithOperationContextSessionIdInitializer() .WithSessionAuthStrategy<Session>() .WithLoginMethod<ILoginService>(s => s.Login()) .WithOperationContextSessionIdResolver() .WithInMemorySessionRepository() .WithStandardSessionCopier()) ) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

System.ServiceModel.ServiceAuthorizationManagerの実装を追加することで認証方法を変更できます。セッション識別子の初期化方法、認証の確認方法、クエリ実行のコンテキストからセッションを抽出する方法、サーバーにセッションを保存およびコピーする方法を変更します。 一般的な場合、AuthorizationBehaviorの登録は次のようになります。

 .AddServiceAuthorizationBehavior(sReg => sReg.WithCustomAuthorizationManager<ServiceAuthorizationManagerImpl>() .WithCustomSessionHeaderInfo<ISessionHeaderInfoImpl>() .WithCustomSessionIdInitializer<ISessionIdInitializerImpl>() .WithCustomAuthStrategy<IAuthStrategyImpl>() .WithLoginMethod<ILoginService>(s => s.Login()) .WithCustomSessionIdResolver<ISessionIdResolverImpl>() .WithCustomSessionRepository<ISessionRepositoryImpl<MySessionImpl>>() .WithCustomSessionCopier<ISessionCopierImpl<MySessionImpl>>())
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クライアント登録も変更されます。

 private static IUnityContainer RegisterWcf(this IUnityContainer container, string serviceIp, int servicePort) { container .RegisterType<ClientSession>(new ContainerControlledLifetimeManager()) .RegisterClientWcf(o => o .RegisterServiceExecutor(reg => reg.Standard() .WithExceptionConverters() .AddFaultToBusinessConverter()) .RegisterChannelWrapperFactory(reg => reg.Standard()) .RegisterServiceConnection(reg => reg .NetTcp(serviceIp, servicePort) .WithBehaviors() .AddSessionBehavior(sReg => sReg .WithStandardSessionHeaderInfo("ExampleNamespace", "SessionId") .WithCustomSessionIdResolver<ClientSession>(new ContainerControlledLifetimeManager()) .WithStandardMessageInspectorFactory<ILoginService>(service => service.Login())))); return container; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果：

作業アルゴリズム

1. クライアントは、 wcfコントラクトで選択されたメソッドを介して承認されます。 認証に成功すると、サーバーはセッションを作成し、リポジトリに保存し、それに関するデータをクライアントに送信します。
   
   
   
   

    var newSession = Session.Create(userId); _sessionRepository.Add(newSession); return new SessionDto { SessionId = newSession.SessionId, Username = "ExampleUserName" };
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

2. クライアントはセッションデータを受信して​​保存します。
   
   
   
   

    var clientSession = container.Resolve<ClientSession>(); var sessionDto = Task.Run(async () => await loginServiceExecutor.Execute(s => s.Login())).Result; clientSession.Session = sessionDto;
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

3. サーバーには、呼び出しクライアントに関するデータを受信する機能があります。
   
   
   
   

    public async Task<ulong> GetFibonacciNumber(int n) { var session = _sessionResolver.GetSession(); _logger.LogInfo( string.Format("User with SessionId={0} and UserId={1} called CalculatorService.GetFibonacciNumber", session.SessionId, session.UserId)); return await _fibonacciCalculator.Calculate(n); }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

4. クライアントには、許可中にサーバーから受信したデータを受信する機能があります。
   
   
   
   

    _logger.LogInfo(string.Format("SessionId {0} with name {1} begin calculate Fibomacci", _clientSession.SessionId, _clientSession.Session.Username));
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

中身は何ですか

インフラストラクチャのほとんどは、System.ServiceModel.dllライブラリによって提供されます。 ただし、より詳細に検討する必要があるソリューションがいくつかあります。



クライアントとサーバー間の対話の基礎は、Rikrop.Core.WcfライブラリにあるIServiceExecutorインターフェイスの実装です。

 public interface IServiceExecutor<out TService> { Task Execute(Func<TService, Task> action); Task<TResult> Execute<TResult>(Func<TService, Task<TResult>> func); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最も単純な場合、チャネルが開き、このチャネルのコンテキストでメソッドが呼び出されます。

 public async Task<TResult> Execute<TResult>(Func<TService, Task<TResult>> func) { using (var wrapper = _channelWrapperFactory.CreateWrapper()) { return await func(wrapper.Channel); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

より複雑な実装では、エラーを変換したり、プロパティの変更によって処理が完了したときに通知することがあります。 これらのアイデアは、IServiceExecutorのWPF実装で最も広く使用されています。ServiceExecutorFactoryを使用すると、DataBindingを使用してUIに長い操作を通知したり、サーバーからの応答を待機しながら任意の情報でポップアップを表示したりできるwcfサービスのラッパーを作成できます。

実装を簡単にするために、主な役割は、登録時のFluentインターフェイスとライブラリインフラストラクチャの標準実装によって果たされます。そのため、スタジオのヒントを使用すると、最も複雑な構造でも初めて理解しやすくなります。







他のライブラリも記事で間接的に言及されています：

• 自動車工場の導入：
  
  
  
  

   private static IUnityContainer RegisterFactories(this IUnityContainer container) { new[] { Assembly.GetExecutingAssembly(), typeof (FibonacciCalculator).Assembly } .SelectMany(assembly => assembly.DefinedTypes.Where(type => type.Name == "ICtor")) .Where(type => !container.IsRegistered(type)) .ForEach(container.RegisterFactory); return container; }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

• ロガーのラッパー：
  
  
  
  

   private static IUnityContainer RegisterLogger(this IUnityContainer container) { container.RegisterType<ILogger>(new ContainerControlledLifetimeManager(), new InjectionFactory(f => NLogger.CreateConsoleTarget())); return container; }
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

まとめ

プロジェクトにインフラストラクチャをセットアップしたら、IServiceExexutorを介した対話のネットワークの性質を長い間忘れることができます。 体系的なアプローチを使用し、mvvmパターンを使用したデスクトップアプリケーションの構築、データベースとの対話 、ロギング、およびその他の一般的なタスクにライブラリを使用するのが最適です。 ただし、馴染みのない、必ずしも馴染みのあるフレームワークを使用したくない場合でも、その基になるアイデアへの応用を見つけることができます。 コンポーネントの拡張性、構成中の厳密なタイピング、すべてのレイヤーでの対話の透過性、インフラストラクチャコードの最小化、およびインフラストラクチャのメンテナンスに費やす時間は、計算機およびマルチユーザーエンタープライズシステムを作成する際に覚えておくべき重要な事項です。 ライブラリを使用する代わりに、プロジェクトによってライブラリコードをダウンロードしてソリューションに接続できます。 これにより、デバッガーの下で作業を学習し、必要に応じて独自の変更を加えることができます。

ボーナス

練習に勝るものはありません。 Rikrop.Core.Wcfの使用の開発とサポートの間のどこかの段階で、かなり大きなプロジェクト（約300,000行のコード）を翻訳した経験があることを学びました。 これは、.net 4.0のasync / awaitで苦しみ、セッションでの作業をカスタマイズし、設定から設定を抽出し、それらをc＃フォームに変換するというかなり興味深い経験です。 これが誰にとっても興味深い場合は、フレームワーク全体をドラッグすることなく、このライブラリへの移行の具体例を説明できます。



また、UIロックを介してユーザーに通知するか、ServiceExecutorFactoryを介して実装されたポップアップを使用したwpfのソリューションもあります。 これはプライベートな例であり、wcfよりもwpfに関連しています。 ただし、これにより、ライブラリの利点と使用の動機に関する詳細な情報が得られます。