Geekly Articles each Day

構成がアプリケーションアーキテクチャに与える影響

シリアライザーを テストするためのテストアプリケーション がNFXライブラリで作成されました 。 これはUnistackライブラリです。 正直なところ、Unistackライブラリの別の例を挙げるのは難しいと思います。 たぶん似たようなものがServiceStackの形であるかもしれません。 NFXとは異なり、ServiceStackは複数のdllにまたがっています。 しかし、最も重要なことは、ServiceStackはUniではなく、そのパーツは少し異なる方法で作られており、NFXのようなグローバルスペースをカバーしていないためです。 ただし、この記事の目的は、Unistackの概念を説明することではなく、NFXを使用する機能の1つです。

NFXの使用はテストアプリケーションにどのように影響しましたか？ 見てみましょう。

テストアプリケーションはコンソールアプリケーションです。 実行し、最終的にテスト結果を取得します。 多くのテストが存在する可能性があり、1つのパスですべての組み合わせですべてのテストを実行するのは愚かです。 NFXなしで何をしますか？ ほとんどの場合、コマンドラインにいくつかのパラメーターを追加して、必要なテストのみを実行します 。 少し作業した後、構成パラメーターをXml構成ファイルに追加し、そこから読み取ります。 おそらく、構成ファイルのappSettingsセクションで、名前が値である単純なパラメーターの配列を使用します。 より複雑な構成構造を構築できますが、.NETでのこのサポートはそれほど単純ではなく、しばらくの間、テスト自体を忘れて、この構成ファイルを開発およびデバッグします。 いいえ、私は複雑な構造を作成しません。なぜなら、それは困難であり、その助けを借りて得られる利点はそれほど大きくないからです。

NFXは複雑な構成を簡単にします。 それは非常に単純なので、テストアプリケーションの設計を劇的に変更します。

NFXについて何も知らないと仮定し、アプリケーションの例を使用して 、これがどのように機能するかを理解しようとします 。

objgraph構成ファイルを開きます。 laconf テスト自体を説明するセクションは次のとおりです。

tests { test { type="Serbench.Specimens.Tests.ObjectGraph, Serbench.Specimens" name="Warmup ObjectGraph" order=000 runs=1 ser-iterations=1 deser-iterations=1 } test { type="Serbench.Specimens.Tests.ObjectGraph, Serbench.Specimens" name="Conferences: 1; Participants: 250; Events: 10" order=000 runs=1 ser-iterations=100 deser-iterations=100 ...


明らかに、テストセクションにはテストセクションのコレクションが含まれ、それぞれが1つのテストのパラメーターを定義します。 最初のパラメーターはtypeです。ここでも、アセンブリ内の型（クラス）を指していることは明らかです。 最初のテストでは、これはそれぞれSerbench.SpecimensアセンブリのSerbench.Specimens.Tests.ObjectGraphクラスです。 他のすべてのパラメーターも、詳細な説明なしで明確です。

シリアライザーについて説明するセクションは次のとおりです。

 serializers { // Stock serializers: they use only Microsoft .NET libraries serializer { type="Serbench.StockSerializers.MSBinaryFormatter, Serbench" name="MS.BinaryFormatter" order=10 } serializer { type="Serbench.StockSerializers.MSDataContractJsonSerializer, Serbench" name="MS.DataContractJsonSerializer" order=20 _include { file="knowntypes.Conference.laconf"} //include file contents } ...

新しいものは何もありません。ファイルを指す_includeコンストラクトが表示されることを除いて、すべてが明確です。

これはすべてJSONに非常に似ています。 これまでの最大の違いは、「：」の代わりに「=」を使用していることです。 それでもコレクションは特別な方法で割り当てられません。JSONでは '[]'です。ここでは同じ '{}'です。

では、コード自体を見て、これらの構成パラメーターを取得するために使用されているAPIを確認します。

構成ファイルで指定されたテストクラスは次のとおりです。

 public abstract class Test : TestArtifact … [Config(Default=100)] private int m_SerIterations; [Config(Default=100)] private int m_DeserIterations; [Config(Default=1)] private int m_Runs;


構成では

  runs=1 ser-iterations=100 deser-iterations=100


およびコード内-パラメーターをわずかに変更しました。 たとえば、m_SerIterationsからは、反復が判明しました。 つまり、構成内の変数はすべて小文字で書かれています。 大文字が見つかった場合、大文字になりますが、先頭に「-」が付きます。 そして、接頭辞「m_」は単に破棄されます。

停止しますが、コードの変数が構成可能になることをどのように理解しますか？ 明らかに[Config]属性を使用します。

構成がどのように設定されているかは明らかです。 どのように使用されますか？ シリアライザーのセクションを理解しようとします。

TestingSystemクラスにあります：

  public const string CONFIG_SERIALIZERS_SECTION = "serializers"; public const string CONFIG_SERIALIZER_SECTION = "serializer"; ... foreach(var snode in node[CONFIG_SERIALIZERS_SECTION].Children.Where(cn => cn.IsSameName(CONFIG_SERIALIZER_SECTION))) { var item = FactoryUtils.Make<Serializer>(snode, args: new object[]{this, snode}); m_Serializers.Register( item ); log(MessageType.Info, "conf sers", "Added serializer {0}.'{1}'[{2}]".Args(item.GetType().FullName, item.Name, item.Order)); } if (m_Serializers.Count==0) ...


今、私はコンテナでの作業を見ています。 構成から各シリアライザーに対して個別のシリアライザークラスが登録されます。

そして、m_Serializersとは何ですか？

  private OrderedRegistry<Serializer> m_Serializers = new OrderedRegistry<Serializer>();


同様のコードは、m_Tests、同じ登録ですが、既にテストクラスです。

doTestRun（）メソッド-1つのテストパスを開始します（runs = 1）。 まず、必要な数のシリアル化反復（ser-iterations = 100）で開始し、次に、必要な数の逆シリアル化反復（deser-iterations = 100）で開始します。 これらのパラメーターはすべて構成で設定されます。

まあ、詳細で、すべてが明確であるようです。 私は戻ってきます。

まとめ


ここでアプリケーションをもう一度見てみると、これはもう数行の構成を持つ典型的なコンソールアプリケーションではないことがわかります。 これで構成が拡大し、C＃のコードと直接サイズが一致しました。 構成は、アプリケーションへのインターフェイスに似ています。 UIはありませんが、コンソールアプリケーションのままですが、 ビジネスロジックがコードから構成にどれだけ移行したのでしょうか。

構成がどれほど面白くなったか。 アプリケーション全体の設定と、個々のクラスの設定があります。 クラスはビジネスオブジェクトのようになりました。

そして-はい、あなたは正しいです。 これで、ビジネスインターフェイスである構成の定義から始めて、アプリケーション全体を開発できます。 その後、クラスとコーディングの設計に直接進むことができます。

追加したものと見返りを得たものをもう一度見てみましょう。

NFXの構成システムを使用し始めました。 最初に、ビジネスインターフェイスを含む構成ファイルを作成しました。



つまり、最初に構成でテストアプリケーションのモデルを説明しました 。

次のステップでは、特定のクラスを作成し、構成に関連付けました。

プログラマーからの質問



ここでは、アプリケーションのコンパイル時ではなく、操作中に構成を特定のクラスに関連付けます。 これにより、 実行 時 エラーの 可能性がどの程度増加し ますか？

はい、たとえば、構成のクラス名を間違えた場合、コンパイル中にこのエラーは検出されず、アプリケーションの操作中にのみ検出されます。 NFXは、アプリケーションの起動時に構成を読み込みます。 したがって、ほとんどのエラーは起動時にすぐに検出され、別のクラスの操作中には検出されません。 この場合、診断はエラーを一意に特定します。 その結果、実行時エラーの確率がわずかに増加します。


すべての NFX は1つの アセンブリに含まれてい ます。 使用しないクラスがたくさんあります。 彼らは邪魔しますか？

NFX用のアプリケーションを初めてコンパイルするときに最初に気付くのは、コンパイルの速度です。 NFXは、プログラマ向けにプログラマが作成したライブラリです。 そして、それは最も重要な場合のために設計されています：数千のサーバー、数百万のメッセージなど。 速度が低下するものはすべてリサイクルされているか、完全に交換されています。 さらに、NFXはサーバー用のライブラリであり、サイズはそれほど重要ではありません。 1.5 MB（NFXサイズ）がクライアントアプリケーションに適しているとは思いませんが。


IoT デバイスで NFX を使用することは可能 ですか？ 彼女には多くの可能性があり、これらはすべて1つのファイルに収められています。

正直なところ、私たちはこれについて考えませんでした。 それでも、NFXは.NET上で実行されることを忘れないでください。 .NETがロードされたデバイスがある場合は、そうではありません。


ご覧のとおり、構成は新しい言語で設定されています。 正直なところ、私は別の言語を学びたくありません。 代替手段はありますか？

はい、あります。 NFXでは、構成をLaconicまたはXMLで記述することもできます。 同時に、LaconicとXMLを切り替えるときに、コードをまったく変更する必要はありません。

構成にJSONではなくLaconicが使用されたのはなぜですか？ JSONほど複雑ではなく、5分で学習できます。 残念ながら、JSONはいくつかの特定の理由により、構成ファイルにはあま​​り適していません。

Source: https://habr.com/ru/post/J263827/

More articles:


All Articles