自転車を発明し、技術を研究した方法

プログラミング言語は何かを作成する過程で最もよく研​​究されるという声明を繰り返し聞いています。 私はこれに異議を唱えることができず、これは言語だけでなく、この言語と共存するあらゆる種類のテクノロジーにも当てはまると判断しました。

未知のトラックを踏みつけることは簡単ではありません。誰かがあなたの前でこのトラックをどのように踏んでいるかを学ぶのはずっと簡単です。 私はドキュメンテーションを勉強するための魂を持っていません。参考書として使用します。また、ゼロから何かを勉強するには、多くの時間と労力がかかります。 また、サイクリングのトピックでは、学習プロセス、熊手などをすべて網羅しています。 残念なことに、興味のあるトピックに関する十分な詳細な記事を見つけられなかったので、最初から最後まで勉強して、自分で記事を書くことにしました。



必要に応じて、プロセス、アプローチ、またはイデオロギーをマスターしたかったのですが、これはTDD（別名テスト駆動開発）と呼ばれます。 また、補助技術として、テストの一部で、Moqテストフレームワークが使用されました。 今後は、「アーキテクト」としての経験も必要なので、完全に正しく開発することはできなかったと言えます。 いくつかのブロックをやり直さなければならず、私が書いたテストケース自体は、クラスが何をどのように行うべきかをまだ完全に認識していませんでした。 しかし、物事は前進し、経験が積まれ、次回はもっと簡単になるはずです。 長い間手作業でマスターしてきた2番目のテクノロジーは、依存関係とIoCコンテナーの実装です。 開発では、最も印象的なAutofacを使用しました。

サイクリングのテーマ

長い間選択する必要はありませんでしたが、解決策は文字通り自分でやって来ました-フィルタリングと設定可能な出力形式で自分のロガーを書くことです。 ASP.NetとMVC3フレームワークに関する最初の記事を書きたかったのです。 ただし、MVC4に移行することはすでに理にかなっています。 ちなみに、テクノロジーの中では、Entity Frameworkを使用することになっています。 主題に関する主題に関する記事は既にありますが、著者は約束を完了せずに姿を消しました。

それでは、なぜロガーによって中断されるのですか？ もちろん、そのアプリケーションを作成する過程で、ログの必要性が生じました。 NuGetでNLogを入手することをお勧めしましたが、それを研究した結果、ロガーを書くことは面白いだけでなく正当であるという結論に達しました。 私は自分でチェックしませんでしたが、インターネットのレビューから判断すると、log4netはそれよりも遅いため、考慮しませんでした。

私自身はテレコムで働いており、標準のsyslogにはない機能が必要になったときは、すでにロガーと連携する必要がありました。 これはIDによるフィルタリングです。 サイトが1時間に3万件の呼び出しを処理する場合、バグが100％再現されたとしても、メガバイト単位やギガバイト単位のログで見つけることはそれほど簡単ではありません。 はい、すべてのシステムでギガバイトのログを保存できるわけではありません。一部の場所では、ラッシュアワーで数分のトラフィックしか取得できないシステムがあり、通話自体の長さが長くなる場合があります。つまり、通話の開始または終了がログに記録されない場合があります。 そのため、「上から」というアイデアが生まれました。コールにマークを付けて、彼だけがログに記録されるようにして正しいことを強調するということです。 さて、またはいくつかの呼び出しが、このバグが定期的に発生する番号にのみ。 syslogは、セッション内の識別子をオペレーターが指定した識別子のリストと比較するマクロに正常に置き換えられました。 識別子は、端末の一意のアドレスとダイヤル番号の両方に関連付けられていました。 私のASP.Netアプリケーションでは、フィルタリングはユーザーIDによって想定されていました。 もちろん、これはここではあまり正当化されないかもしれませんが、ロガーがこの機能を必要とすると決めたので、そうする必要があります。

NLogのソースコードを調べて見つけた2番目の自転車の機会。 その中で、ほとんどすべてのアクションは呼び出しスレッドのコンテキストで実行され、非同期的にターゲットへの直接書き込みのみが実行されます。 後で確信したように、それはパフォーマンスにかなりのダメージを与えます。

別のスレッドに操作を配置する

この操作はすぐに別のクラスにカプセル化しました。 クラスは、すべてのメッセージが処理されるストリームを開始し、これらのメッセージをこのストリームに送信できるようにします。 メッセージには、ログのテキスト、レベル、およびその他の情報が含まれます。 これはタスクを解決するために必要です-ログを送信するスレッドのコンテキストでアクションの数を最小限に抑えるため。

基礎として、Visual Studioに含まれている言語サンプルからThreadSyncの例を取り上げました。 ファーストクラスのインターフェース：

public delegate void ReceiveHandler<T>(T item); public interface IQueued<T> { event ReceiveHandler<T> OnReceive; event Action OnTimeout; bool Active { get; } void setTimeout(int timeout); void Send(T msg); void Terminate(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フラグは、ThreadRun内部メソッドの開始時に設定され、終了時にリセットされます。 OnReceiveイベントは、ストリームが新しいメッセージを受信したときに発生します。 引数デリゲート型のキャストを回避するために、イベントデリゲート型が作成されました。 タイムアウトは、ディスクへの直接書き込みではなく、たとえばStringBuilderなどの最初のバッファへの書き込みを許可するために作成されました。 最後のメッセージを受信して​​から指定した時間が経過すると、OnTimeoutイベントが1回トリガーされ、最後に受信したログがディスクに送信されることが保証されます。

クラスには2つのオプションがあり、理由に応じて選択できます。 1つのオプションはスレッドを開始しますが、Terminateを呼び出す必要があります。

 thread = new Thread(ThreadRun); thread.Start();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同じインターフェイスを実装する2番目のクラスは、独自のメソッドを標準のThreadPoolに追加します。 特に、メインアプリケーションが既にプールの複数のスレッドを使用している場合、このスレッドは開始時に非常に遅れることがあります。 1つの喜び-Terminate（）を呼び出して完了する必要はなく、アプリケーションを閉じると自動的に閉じます。

 ThreadPool.QueueUserWorkItem(ThreadRun);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンストラクターは、入力としてManualResetEventを受け入れます。この入力は、スレッドで動作する複数のクラスに供給され、集中化されたアプリケーション終了イベントとして使用されます。 ロガーではこれを使用しませんでしたが、念のためこの機会を追加しました。 完了イベントに加えて、イベントも機能するために使用されます。これは、新しいメッセージがキューに到着したことを意味します。 こんな感じ

  EventWaitHandle[] events = new EventWaitHandle[2]; ... events[0] = new AutoResetEvent(false); events[1] = terminateEvent ?? new ManualResetEvent(false);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、Terminateメソッドのタスクがイベント[1]を1に設定することであることは非常に明白です。

送信したメッセージを保存するために、キューキューを使用しました。 Send（）メソッドは、例から単純にコピーされます：

  lock (queSync) { queue.Enqueue(msg); } events[0].Set();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

反対側でメッセージを受信するために、「収集」ストリームによるキューブロックの時間を最小限に抑えるために、ちょっとしたトリックに頼ることにしました。 そのため、キュー自体ではなく、個別に作成されたオブジェクトに対してロックが行われます。 受信スレッドは無限ループ内でスピンし、インデックスが1に等しい場合に出力が生成されます。つまり、前述のように、Terminateメソッドまたは外部から呼び出されたイベント[1]が機能したことを意味します。

  while ((index = WaitHandle.WaitAny(events, currentTimeout)) != 1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

WaitAnyメソッドは、イベントの1つがトリガーされるか、デフォルトでタイムアウトが無限に設定されるまでスレッドをブロックします。 つまり、ロガーのフローはスリープし、ログの送信を開始するまでアプリケーションのパフォーマンスに影響を与えません。 トリガーされると、まず、タイムアウトが発生したかどうかを確認し、対応するイベントをアクティブにします。

  if (index == WaitHandle.WaitTimeout) { OnTimeout(); currentTimeout= Timeout.Infinite; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここの2行目は、ユニットテストのために正確に表示されましたが、コーディング中に見逃しました。 それ以外の場合は、キューからメッセージを取得する必要があり、各メッセージでOnReceiveイベントが発生します。 先ほど言及した「トリック」は、コードに表示されています。

  Queue<T> replacement = new Queue<T>(); Queue<T> items; lock (queSync) { items = queue; queue = replacement; } foreach (T t in items) { OnReceive(t); } currentTimeout = timeout;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスのすべての重要なポイント、まあ、またはモジュールについては、他のすべてのクラスと同様に、その完全なコードがリポジトリにあります。記事の最後にリンクを掲載し、この免責事項を繰り返しません。

すでに記事を書いている時点で、ConcurrentQueueを使用して同じことを行うというクレイジーなアイデアが思い浮かびました。当然、上記のトリックはなく、完全にブロッキングはありません。 同時に、両方のタイプのストリームを作成する可能性を何らかの形で残す必要があります。 したがって、インターフェイスの背後にストリームの作成をカプセル化することにしました。これをIStarterと呼びます。クラスはそれぞれ単一のメソッドで構成されます。 ちなみに、ここではラムダ式を使用することは非常に可能ですが、私のエステティストはこれに反対しました。 その結果、「ブリッジのこちら側」にはロックとインターロックの2つのクラスがあり、「ブリッジの反対側」には2つのクラスがあり、それらのフローを開始する2つのオプションがあります。任意の組み合わせで使用できます。 GoFの「実装ではなく、インターフェイスと対話する」というイデオロギーの魅力（c）は、データと対話する他のクラスに触れる必要がないという事実だけでなく、単体テストも変更する必要がないという事実で表されます。 。 絶対に。 特定のオブジェクトを作成するポリモーフィックな方法を変更するだけで、すべてのオプションにこれらのテストが提供されます。

TDDの始まり

私はこのトピックについて少し理論的です。 最初に、最初のクラスと2番目のクラスが同じクラスの例では、TDDでは開発動作を要約できませんでした。最初にテストを行い、次にコード自体を作成しました。 私の開発の道筋は、次の段階を経ました。動作するコードを作成し、テストケースを作成し、最初と2番目の両方を調整して、標準にしました。 その後、テストは「真であると認識」され、後に続くリファクタリングはおそらくそれらに基づいている可能性があります。 少なくとも初心者にとって、このアプローチには生命の権利があると考える理由：最も単純な関数A = B + Cを考慮する場合、この関数のテストは式C1 = A-Bで提案され、比較Cに基づくテストの成功の結論== C1。 ここでのエラーは、テストされた機能とテストされた機能の両方に含まれている可能性があります。 さらに、アクションが多いため、ミスが発生しやすくなります。 この時点で、なぜテストが必要なのか疑問に思うかもしれませんが、答えは自然にすでに存在し、すべてが私たちの前に定式化されています。 テストで「合格」を示すには、条件の1つが満たされている必要があります。 両方の機能にエラーがないか、あちこちにエラーが同時に存在しています。 両方のエラーが発生する確率は、それぞれのエラーの確率よりも個別に小さくなります。特に、ここに存在するだけでは十分ではないため、エラーが相乗的である、つまり相互の影響を補償する必要がありますが、その確率はさらに低くなります。 つまり、テストを記述するすべての努力は、エラーの可能性を減らすことを直接目的としています。 ただし、同じ人がテストとコードの両方を書く場合、同じ間違いをする確率はわずかに高くなります。 さて、大丈夫、私にとっては自転車のようです、そして何がすでに良いですか。

最初のテストの作成に移りましょう。 これを行うには、まずIQueuedインターフェイス名を右クリックし、対応するメニュー項目を選択して、テストテンプレートを作成します。 したがって、このクラスをテストするには何が必要です。 単独でテストすることになっているので、サブジェクトクラスと対話するクラスのmoki（模倣者）を作成する必要があります。 別のポイント-テストの目的はインターフェイスを選択することであり、最初にテストする特定のクラスが2つあり、後で2対2の4つの組み合わせがあったため、新しく作成したテストクラスに抽象修飾子を付けて汎用パラメーターを追加するのが理にかなっています。

  [TestClass()] public abstract class IQueuedTest<T>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラスは抽象クラスなので、テストはクラスに対して直接実行されません。もちろん、クラスから継承されたすべてのテストクラスが実行されます。

まず、サービスクラスのコンシューマシミュレータが必要です。

  class Tester<T1>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスは、テストされたクラスのイベントをサブスクライブし、イベントのトリガーを検討し、このイベントで何が起こったかを記憶します。

  public Tester(IQueued<T1> tested) { tested.OnReceive += Received; tested.OnTimeout += TimeOut; } void TimeOut() { timedCount++; } void Received(T1 item) { Thread.Sleep(delay); receivedCount++; lastItem = item; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この内部クラスに加えて、特定のオブジェクトを作成するメソッドが必要になります。これにより、すべての相続人がオーバーライドする必要があります。

  protected abstract IQueued<T> createSubject(); protected abstract T CreateItem();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

だから、実際にテストを書くことに。 ちなみに、そのような記事を読んでいると、著者はレーキを省略し、既成のソリューションを提供していることに気付きました。 いくつかのレーキについて詳しく説明します。 私が最初に遭遇した問題は、スレッドプールでの開始の同じ遅延でした。 アプリケーションが起動すると、プールは少数のスレッドのみを保持し、新しいスレッドを10分の1秒で測定される遅延でのみ起動します。 そして、テストフレームワークはテストを並行して実行しているようです。 このため、「手動」フローを使用したテストは成功しましたが、プールからのフローでは一部が合格し、一部は落ちました。 したがって、2つのオプションがあります。同じ「長い」メソッドですべてのテストを選択します。これはより高速に実行されますが、一般的な判定を1つだけ発行するか、回避策を考え出します。 私は次のことを思いつきました：

  void ActivationTestHelper(Tester<T> tester, IQueued<T> subject) { int retry = 30; while (!subject.Active && retry > 0) { retry--; Thread.Sleep(SleepDelay); } Assert.AreEqual(true, subject.Active); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

30は、ストリームがアクティブになるまで「待機」を試み、その後はテストのみに進みます。 ヘルパーは作成後すぐに呼び出されます。

そして、再び-そう、テストを書くことに。 最初のテストは、メッセージを送受信することです。 クラスのタスクは別のスレッドに転送することであることがわかっているため、テスタークラスが送信ストリームのコンテキストでメッセージを受信しないことを確認し、その後正常に受信することを確認する必要があります。 ちなみに、テスターがReceivedメソッドのコードで50ミリ秒の遅延を持っているのは、このため（最初の場合）です。 この遅延が呼び出しスレッドで発生した場合、最初のアサートはテストに失敗します。

  [TestMethod()] public void SendTest() { var subject = createSubject(); var tester = new Tester<T>(subject); ActivationTestHelper(tester, subject); T item = CreateItem(); tester.delay = SleepDelay; subject.Send(item); Assert.AreEqual(0, tester.receivedCount);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、メッセージが送信されたことを確認するために、100ミリ秒待ってから受信したメッセージを確認します。 原則として、これらの値は減らすことができます。主なことは、2番目の遅延が最初の遅延よりも大きいことですが、ここでは、これは原理的ではないと思います。 以下のテストに「道を譲る」ために、フローを完了することを忘れないでください。

  Thread.Sleep(SleepDelay2); Assert.AreEqual(1, tester.receivedCount); Assert.IsTrue(tester.lastItem.Equals(item)); subject.Terminate(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、タイムアウトテスト。 また、オブジェクトを作成し、アクティベーションヘルパーを実行します。 タイムアウトを設定し、呼び出し元スレッドのコンテキストでは呼び出されず、後で呼び出されることも確認します。 そして一度だけ。

  [TestMethod()] public void TimeoutTest() { var subject = createSubject(); var tester = new Tester<T>(subject); subject.setTimeout(SleepDelay); ActivationTestHelper(tester, subject); T item = CreateItem(); subject.Send(item); Assert.AreEqual(0, tester.timedCount); Thread.Sleep(SleepDelay3); Assert.AreEqual(1, tester.timedCount); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このテストでは、タイムアウト値の4倍である200ミリ秒の遅延が設定されました。最初のエラーである見落としをキャッチしたのはこのテストでした。 単体テストは快適であることが判明しました。これは、エラーの絶対的な大部分が「プロダクション」だけでなく、アルファトライアルにも及ばないことを意味します。 もちろん、これらのエラーはそこで検出されますが、テストの記述に費やされた作業は、デバッグのために行われなければなりません。 その結果、緊急事態が「怠techniqueな」開発期間にあった期間から一定量の作業をシフトする一種の時間管理技術ができました。 そして、これらすべては、リファクタリングにおける貴重な助けに言及しなくても、私が途中で発明したものです。

残りのテストは、ストリームの完了です。 ストリームが停止され、どこにも何も送信されないことを確認する必要があります。 すべてのテストに共通の手順を省略すると、次の結果が得られます。

  public void TerminateTest() { ... subject.Terminate(); subject.Send(item); Thread.Sleep(SleepDelay3); Assert.AreEqual(0, tester.receivedCount); Assert.AreEqual(0, tester.timedCount); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インターフェイスには3つのテストしかありませんが、2つの特定のクラス、ストリームを開始するための2つのオプションがあり、その上で、送信メッセージとしてのクラスと構造の動作を個別に確認することにしました。 なぜ8つの特定のテストクラスが作成され、そのうちの1つを指定します。特定のテストケースの数は24です。テスト構造：

  public struct TestMessageStruct { public string message; //object reference field public int id; //value field }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして実際には、オプションをテストする特定のテストクラス：ブロックされたキュー、通常のスレッド、構造。

  [TestClass()] public class IQueuedLockRegTest : IQueuedTest<TestMessageStruct> { protected override IQueued<TestMessageStruct> createSubject() { return new LockQueued<TestMessageStruct>(new RegularThreadStarter()); } protected override TestMessageStruct CreateItem() { var item = new TestMessageStruct(); var rnd = new Random(); item.id = rnd.Next(); item.message = string.Format("message {0}", item.id); return item; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これに関連してやり直さなければならない特定の実験オブジェクトを作成したのは、特定のテストクラスでした。 また、その数を2倍にしなければなりませんでしたが、ご覧のとおり、テスト自体を記述し、熟考するときよりも大幅に少ない時間と労力しかかかりません。

ロガーインターフェイスと最初のフィルターレイヤー

私は、インターフェースをNLogのように作成することにしました。 静的クラスLogAccessと呼ばれたのは、何らかの理由で、意味の点で、より論理的に思えた。 彼は自分で何もせず、プロキシのみが呼び出します。 このため、彼はテストに参加しないため、ここでは詳しく説明しません。「外部」に表示される主要なメソッドのみをリストします。最初のメソッドでは、ロガー自体をスパムメッセージに取得できます。 最初のフィルタリングレイヤーにあるロガーの名前またはカテゴリは、前のセクションで説明したクラスを通過する前にこのフィルタリングが実行されることを意味します。つまり、ログのカテゴリごとにレベルを個別に設定できます。 それぞれ、2番目のフィルターレイヤーにカテゴリが存在しないということは、このフィルターがロガーストリームで既に行われていることを意味します。

 Logger GetLogger(string category) void SetLevel(string category, int level) void SetLevelForAll(int level) void FilterAddID(int id) void FilterRemoveID(int id)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

外部から見える2番目のクラスはLogLevelです。 テレコムから取った意味のレベル。 その後、NLogを単純化し、通常のintをレベルとして使用して、レベルの比較などを賢くしないことにしました。

彼は、すべてのレベルのみを追加して、短縮と詳細の2つのデバッグレベルを作成しましたが、実際には不足していました。

  public const int Invalid = 0; public const int Always = 1; public const int Fatal = 2; public const int Error = 3; public const int Warning = 4; public const int Info = 5; public const int Event = 6; public const int Debug = 7; public const int All = 8; public const int Total = 9;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

LogAccessからレベルを設定するために、クラスにDefaultプロパティも含めました。

最も重要なことは、外部から見えるのはLoggerインターフェースです。 意図的にプレフィックスIを追加しませんでした。いくつかのメソッドを提供します。

 public interface Logger { /// <summary> /// Method for unrecoverable errors. /// </summary> /// <param name="message"></param> /// <param name="ex"></param> void Fatal(string message, Exception ex = null); /// <summary> /// Method for external errors, such as user input or file access. /// </summary> /// <param name="message"></param> /// <param name="id"></param> /// <param name="ex"></param> void Warning(string message, int id = 0, Exception ex = null); /// <summary> /// Method for regular debug logging. /// </summary> /// <param name="message"></param> /// <param name="id"></param> void Debug(string message, int id = null); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エラーのメソッドは識別子に関連付けられておらず、警告レベル以上にのみ関連付けられています。

次に、表示する特定のロガーのクラスを検討します。 ロガーが呼び出しスレッドから取得するパフォーマンスの実際の最小化はどのように達成されますか。 ところで、ロガーインターフェイスには拡張バージョンがあり、外部からは見えないため、SetLevelメソッドが追加されています。

  class CheckingLogger : InternalLogger { bool[] levels = new bool[LogLevel.Total]; Sender send; string category; public CheckingLogger(string category, Sender sender, int level) { this.send = sender; this.category = category; SetLevel(level); } public void SetLevel(int level) { for (int n = LogLevel.Fatal; n < LogLevel.Total; n++) { levels[n] = (n <= level); } } public void Error(string message, Exception ex = null) { if (levels[LogLevel.Error]) { send(new LogItem(category, LogLevel.Error, message, ex: ex)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1つのスパム送信方法を検討するために、配列からブール値をチェックし、それをSenderデリゲート経由で送信することは明らかです。 ロガーの2番目のバージョンでは、ブール配列の代わりに送信者の配列が使用され、空のメソッドへのデリゲートがオフレベルに挿入され、送信メソッドにチェックがなく、すぐに送信されます。 テスト結果によると、パフォーマンスの違いはわずかであり、おそらく異なるプラットフォームでテストすることで答えが得られます。 ロガーテストは非常に簡単で、メッセージが送信者に送信されたかどうか、送信すべきタイミングと送信すべきでないタイミングを確認します。 それから、タイプミスやコピーアンドペーストのエラーにも遭遇しました。 ほとんど同じメソッドがたくさんありますが、その違いは一見しただけではわかりません。

クラスに入るセクション、または実際にログを送信するために使用するLogItem構造を考え出すことはできませんでした。ここでは、コンストラクターは省略し、コンテンツのみを省略します。 ちなみに、1つのメッセージのIDを複数に設定できることがわかります。これは、ブロードキャスト、または呼び出しの場合に、発信者と呼び出しに応答する2つの識別子を示すために必要です。 前のクラスのメソッドはこの目的のために複製されており、注意が奪われているだけです。

  struct LogItem { public readonly String category; public readonly String message; public readonly int[] ids; public readonly int level; public readonly Exception ex; public readonly DateTime time; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

依存性注入

このセクションでは、IoCコンテナーの使用例を示します。 次の行はロガーのクラスです。 名前はIoCコンテナに関連付けられておらず、一致するだけです。 LogAccessクラスメソッドがプロキシされるGetLoggerメソッドを提供します。 NLogは、コード内のコメントから判断すると、同じカテゴリで2回呼び出されたGetLoggerメソッドが同じロガーインスタンスを与えることを保証しません。 私はこの方法がボトルネックにならないことを考え、決定し、一般的な同期を設定しました。この場合、インスタンスは同じものを保証する必要があります。 ログコンテナは、以前に作成されたすべてのロガーを保存し、LogAccessからプロキシされたSetLevelを配布します。

そのため、IoCコンテナーを作成し、次の2行の間にさらに構成を配置します。

 var builder = new ContainerBuilder(); IContainer container = builder.Build();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記から、クラスがシングルトンでなければならないことは明らかです。 これは非常に簡単に実現できます。

  builder .RegisterType<LoggerContainer>() .SingleInstance();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次の方法では、シングルトンへのリンクを取得できます。

  Container .Resolve<LoggerContainer>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ログコンテナー自体が作成元のIoCコンテナーのサービスを使用できるように、コンストラクターでIComponentContextパラメーターを追加しました。 これにより、クラスの作成を外部に持ち、特定のクラスを、たとえば、使用するコードを変更せずに、機能を拡張したクラスに変更できますが、構成を変更するだけです。 コードに設定するのではなく、xmlから読み込むことができます。 実際、この内部作成から外部作成への置き換えは、依存関係の実装と呼ばれます。 実際には、コンテキストから特定のロガーを受け取るメソッド：

 private InternalLogger CreateLogger(string category) { return context .Resolve<InternalLogger>(new NamedParameter[]{ new NamedParameter("category", category), new NamedParameter("level",LogLevel.Default) }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, , , , , . , , .

  builder .RegisterType<CheckingLogger>() .As<InternalLogger>();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, , , . , , , . , , . «» .

, IoC: -. :

  [TestClass()] public class LoggerContainerTest { IContainer testContainer; public LoggerContainerTest() { var builder = new ContainerBuilder(); builder .Register<LoggerContainer>((c, p) => new LoggerContainer(c.Resolve<IComponentContext>())); builder .RegisterType<LoggerMock>() .As<InternalLogger>(); testContainer = builder.Build(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, Autofac, new, Resolve, , , , .

.

  LoggerContainer lc= testContainer .Resolve<LoggerContainer>(); var logger1 = lc.GetLogger(cat1); var logger2 = lc.GetLogger(cat2); var logger3 = lc.GetLogger(cat1); Assert.AreEqual(logger1, logger3); Assert.AreNotEqual(logger1, logger2);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Moq

, . , LogCollector-. IQueued , , .

, , , , LogItem. , .

NLog: layout="${longdate} ${uppercase:${level}} ${message}".

LogMessageFormat=\d \l \m\r\n.

, , , . , . , , . , StringBuilder LogItem . , .

, , , . , , , . — , HashSet, . , , . Action . filterQue = new ConcurrentQueue<Action<HashSet>>();

, , , , .

  Action<HashSet<int>> refresh; while (!filterQue.IsEmpty) { if (filterQue.TryDequeue(out refresh) && refresh != null) { refresh(filter); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, , .

  filterQue.Enqueue((x)=> { x.Add(id); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Moq — , , , , . Moq , . — . , GoF, « », , , - , , , , .

Moq — , , internal , , , Moq , , . AssemblyInfo.cs , , :

 [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("LoggerTest"), System.Runtime.CompilerServices.InternalsVisibleTo("DynamicProxyGenAssembly2")]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, , , .

, -, , , .

  LogItem message = new LogItem(category, level, msg, ids, GetException()); var qThread = new Mock<IQueued<LogItem>>(MockBehavior.Strict); var writer = new Mock<ILogWriter>(MockBehavior.Strict); qThread .Setup(s => s.Send(It.IsAny<LogItem>())); writer .Setup(s => s.GetTimeout()) .Returns(timeout); qThread .Setup(s => s.SetTimeout(It.IsAny<int>())); LogCollector target = new LogCollector(qThread.Object, writer.Object); qThread .Verify(s => s.SetTimeout(It.Is<int>(a => a == timeout))); target.Send(message); qThread .Verify(s => s.Send(It.Is<LogItem>(i => i.Equals(message))), Times.Once()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, : . Strict , , , , .

Send IQueued , , . , , VerifyAll(). , . , GetTimeout, , . SetTimeout.

, , , GetTimeout . , , , . , , .

, , , , Moq.

負荷試験

NLog, , , . , .

.

 var log = SharpLogger.LogAccess.GetLogger("flooder " + tid); foreach (var x in Enumerable.Range(0, messageCount)) { log.Info("Message", x); if (x % 1000 == 0) Thread.Sleep(0); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

NLog.

  var log = NLog.LogManager.GetLogger("flooder " + tid); foreach (var x in Enumerable.Range(0, messageCount)) { log.Info("Message"); if (x % 1000 == 0) Thread.Sleep(0); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

tid, , .

, , , , . 200 . . — , , 5 — NLog. , .



.



x64 .



— , Nlog, , , , , . , 40 , .



, — 7.15 ., , 25 . , , , , , NLog , , , . , NLog , .

, — .

, 3 15 , 22.2 17.8. 30, , 1.5 , 23.7 , 17.4, .

, 4 i5 4, windows 8.



https://github.com/repinvv/SharpLogger

, – .