🕳️ 👩🏻‍🔬 ☝🏿 .Net Frameworkに基づくユニバーサルデータコンバーター 🧙🏾 👾 👨🏾‍🍳

この記事では、ユニバーサルデータコンバーターの作成におけるチームの経験をお伝えしたいと思います。一見簡単そうに聞こえますが、何がそんなに複雑なのでしょうか？あるタイプのデータを別のタイプに導きます。データが構造体である場合また、フィールドマッピングを実行するだけで、難しくはありません。はい、簡単です。しかし、複数のターゲット構造がある場合、それらはすべて複雑であり、変換はオンザフライで必要です。また、データを充実させる場合でも、「考えなければならない」と言われています。

チームは次のタスクを担当しました。

1つの構造から複数の他のターゲット構造へのデータコンバーターを記述します。さらに、ソースデータと宛先データを保存する形式は完全に任意です。変換は、再利用および編集の可能性があるルールに基づいている必要があります。変換プロセス中に、一部のデータをトランスコードする必要があります。たとえば、ストリング「＃ff0000」をストリング「red」に変換します。

さらに、ご存知のように、ユーザーが読み取りおよび編集できるようにしたいすべての統合変換、つまり開発した機能は、編集機能を備えたUIに送信する必要があります。

それでは始めましょう。理論的には、入力および出力形式は任意のタイプ（csv、jsonなど）にできます。明確にするために、XML形式を選択します。

XMLソースの例は「変換FROM」です。

<Car> <Color>#ff0000</Color> <Length>5296 cm<Length> <Width>1848 cm</Width> <Price>31000 USD</Price> </Car>

XML宛先の例は「変換先」です。

 <Vehicle> <Body> <Exterior> <Color>red</Color> </Exterior> <Size> <MeasureUnit>ft</measureUnit> <Length>17.3753</Length> <Width>6.0630</Width> </Size> </Body> <Msrp> <Currency>RUB</Currency> <Value>1600000</Value> </Msrp> </Vehicle>

ご覧のように、途中で再計算と変換が発生します。構造内の値の配置が変わるだけでなく、そのタイプも計算された値があり、ソースデータには最終形式への正常な変換に必要なすべてのデータがありません（強化が必要です）。いくつかリストします。

ソースのCar.Color車の色はRBGコード「＃ff0000」として表示され、宛先では、Vehicle.Body.Exterior.Colorタグの「red」の音声解釈に変換する必要があります。
Car.Lenght車の長さは、いくつかのコンポーネント、測定値と測定単位に解決され、アメリカの足に変換される必要があります。結果の値はVehicle.Size.Lengthに入れられます。
Car.Price車の価格もそのコンポーネントに解決され、Vehicle.Msrpに入れられた変換日にルーブル単位で中央銀行レートで変換されなければなりません。

データアクセス用のコンテナの選択

次のように、XML形式を直接操作することはできません。第一に、それはテキストであり、第二に、フォーマットに添付されないという要件があります。この場合、コンピューターのメモリ内のコンテナーオブジェクトを操作することは論理的です。コンテナーオブジェクトには、データにアクセスするための便利なインターフェイスがあり、パーツにリンクするための構造型があります。

このため、構造がストレージのデータと正確に一致する通常のC＃クラスが最適です。 XMLが入力され、XSDスキーマが利用可能な場合、このクラスの作成は大幅に簡素化されます。ユーティリティを使用すると、クラスを自動的にコンパイルし、不必要な労力なしでコードで使用できます。

以下に、構造のクラスについて説明します。

C＃コンテナーコンテナークラス：

 public class Car { public string Color; public string Length; public string Width; public string Price; }

C＃宛先コンテナクラス：

 public class Vehicle { public Body Body; public Msrp Msrp; } public class Body { public Exterior Exterior; public Size Size; } public class Msrp { public string Currency; public decimal Value; } public class Exterior { public string Color; } public class Size { public string MeasureUnit; public decimal Length; public decimal Width; }

ソースデータをコンテナにロードする

.Net Frameworkには、XMLデータの逆シリアル化を実行する既製のコンポーネントがあり、その助けにより、クラスのインスタンスにソースデータが自動的に入力されます。

ファイルがより具体的な形式である場合、データをロードするためのカスタムライブラリを記述することは難しくありません。

コンテナデータへのアクセス

最初に学習する必要があるのは、任意の構造を持つコンテナデータにアクセスする単一の方法を持つことです。すなわちコンテナのメタデータにアクセスする必要があります。これは、.Netリフレクションによって解決されます。クラスの任意のプロパティまたはフィールドにアクセスし、変更可能なデータのタイプと場所を知ることができます。

構造要素（ノード）を直接示すために、XMLのXPathアナロジーを使用します。たとえば、ソースで必要なノードを指定するには、「Car.Color」という行を指定するだけです。

ソースコンテナーデータを宛先コンテナーに変換するためのルール

したがって、2つのコンテナがあり、どちらも構造化されたアーキテクチャを持っています。次に、ソースコンテナーから宛先コンテナーに変換する方法を学習する必要があります。

問題のステートメントで示されているように、変換は一連のルールに基づいている必要があります。ルールは、再利用できるように普遍的でなければなりません。

次の相互作用スキームはコードに隠れています（下図を参照）：データはXMLから.Netオブジェクトにシリアル化され（1-2）、その後コンテナーデータにアクセスすることにより（2）、変換はルールのリスト（3）から宛先コンテナー（2）に進みます-3-4）。さらに、ルールにはデータを充実させる機能があります（3-3'-3）。宛先コンテナが初期化された後、データは最終形式（4-5）にアップロードされます。

スキーム1.コンバーター内のコンポーネントの相互作用のスキーム：

次に、ルールを使用して変換メカニズムを開発します。彼らの助けを借りて、私たちはあらゆる転換を説明できなければなりません。

新しいルール言語を作成し、その言語用に別のコンパイラまたはインタープリターを実装することは、明らかに不要です。常にコンパイルして既存の機能に接続できる通常のC＃コードを使用することにしました。いくつかのC＃インターフェイスと基本クラスが開発されました。

コンバーター自体：

 public interface IConverter { T Convert<T>(Object source, IDictionary<string, ConversionRule> rules) where T : class, new(); ... }

、ルールリストはIDictionary <string、ConversionRule>で、文字列キーは宛先コンテナーのデータへのパスです（例： "Vehicle.Msrp"）

そして、変換ルール：

 public abstract class ConversionRule { public abstract object GetValue(object source); ... }

コンバータのタスクは、ルールのリストに従って、指定されたソースオブジェクトsourceをタイプTの新しいオブジェクトに変換することです。

「ソース」を「宛先」に変換するとき、コンバーターは次のアクションを実行します。

タイプT（宛先コンテナタイプ）のインスタンスを作成します
タイプT（宛先コンテナ）のターゲットオブジェクトの各フィールドとプロパティを再帰的に実行し、対応する変換ルールを検索し、初期化（ルールに基づいて計算された値の割り当て）を実行します。ルールは見つかりませんが、ノードは空のままです。

各ルールには、入力コンテナーソースオブジェクトが入力に渡されます。ルールは計算を実行し、結果の値を返す必要があります。例からわかるように、変換ルールには厳密な型指定はありません。オブジェクトを入力に渡すことができ、出力ではオブジェクトも取得できます。

Car.Priceが車の価格を取得し、それをコンポーネントに解析し、中央銀行のレートでルーブル（変換日）で再計算し、ターゲットコンテナーのVehicle.Msrpに値を書き込むというルールの例を考えます。

以下は、変換ルールの設定表です。

宛先の宛先ノード	変換ルール（アセンブリ内のクラス）	変換ルールのパラメーター
Vehicle.Msrp	ConvertStringPriceToMsrp	TargetCurrency =“ RUB”、SourcePath =“ Car.Price”

カスタム変換ルールクラスの例：

 public class ConvertStringPriceToMsrp: ConvertionRule { public string TargetCurrency; public string SourcePath; public override object GetValue(object source) { var targetObject = new Msrp(); targetObject.Currency = TargetCurrency; targetObject.Value = SplitAndCalc(GetFiled(source(), SourcePath, TargetCurrency); return targetObject; } ... }

ルールを開始する前に、リフレクションを介してフィールドとプロパティをソートし、構成から同じ値のTargetCurrency、SourcePath（ルールの特定のインスタンスのパラメーターのセット）を入力することで初期化されます。

このルールを処理するConvertStringPriceToMsrpオブジェクトは、Car.Priceソースコンテナーのフィールドの値を取得し、文字列を価格と通貨のコンポーネントに分割し、Msrp.Curreny = RUBおよびMsrp.Value = [ルーブルの価格]フィールドを埋めて、結果のMsrpオブジェクトを作成します。

説明からわかるように、ルールは現在のルーブルからドルへの為替レートを取得するために、まだ外部データソースに連絡する必要があります。すなわち変換ルールは、任意の外部データソースに接続して、データを強化できます。

コンテナから宛先データをアンロードします

データは、オブジェクトをシリアル化することにより、既製の.Net Frameworkライブラリによって、同じ方法でXMLのターゲットオブジェクトからアンロードされます。コンポーネントは、クラスのフィールドとプロパティのデータをXML構造にきちんと結合します。

宛先ファイルも特定の場合は、アダプターを作成する必要があります。アダプターは、宛先コンテナーが目的の形式で保存します。

美徳と挑戦の有効なプロトタイプ

サービス参照ライブラリの自動読み込み（データの強化、再利用可能な参照ブック）のために、IoC Autofacを実装しました。したがって、大量の同種データを変換するときに、I / Oの過剰な負荷の問題を解決し、処理を加速しました。

ターゲットへの変換は、不要なサイクルなしで単一パスで発生します。

再帰性があるため、ノードの値をオプションで「選択する」に置き換えることができます。このオプションは、あるタグの構造が別のタグに依存している場合（たとえば、製品のタイプによって異なるタグが入力される-Amazon APIでXMLを生成するときにこれを積極的に使用します）、XMLに非常に役立ちます。

同時に、メタデータを使用したすべての作業はリフレクションに基づいており、将来的には速度の問題が発生する可能性があります。この問題は、反射率計算の遅延がコンバーターのルール内の高速計算で私たちを支配するときに明らかになります。現時点では、このような問題はまだ発表されていません。ただし、表示される場合、つまり、宛先コンテナのタイプをバッチ処理でキャッシュするという考え方です。

ユーザーが設定をすばやく変更できるように、すべてのルール設定をWebインターフェイスに対して行いました。変換設定は最初はXMLで保存されていましたが、編集を簡単にするために、データベースに転送することにしました。

すべての長所と短所がありながら、目的の「.Net Frameworkに基づくユニバーサルデータコンバーター」が得られました。現在、彼はアマゾン、ウォールマート、その他のトレーディングフロアで商品を公開するためのモジュールに積極的に取り組んでおり、データの継続的なマッピング、変換、および強化が必要です。

.Net Frameworkに基づくユニバーサルデータコンバーター