2

.NET でアプリケーション (クラス、クラス ライブラリのインターフェイス) をどのように設計しますか? 固定データベース設計があり、サード パーティのデータ ソースからのデータのインポートをサポートする必要がある場合、おそらく XML になりますか?

たとえば、ID タイトル 説明 税レベル 価格 の列を持つ製品テーブルが DB にあるとします。

反対側には、たとえば Products: ProductId ProdTitle Text BasicPrice Quantity があります。

現在、私は次のようにしています: サードパーティの XML をクラスと XSD に変換し、そのコンテンツを強い型指定されたオブジェクトに逆シリアル化します (このプロセスの結果として得られるのは、ThirdPartyProduct、ThirdPartyClassification などのクラスです)。

次に、次のような方法があります。

InsertProduct(ThirdPartyProduct newproduct)

現時点ではインターフェイスを使用していませんが、使用したいと考えています。私が望むのは、次のようなものを実装することです

public class Contoso_ProductSynchronization : ProductSynchronization
{
    public void InsertProduct(ContosoProduct p)
    {
        Product product = new Product(); // this is our Entity class
        // do the assignments from p to product here

        using(SyncEntities db = new SyncEntities())
        {
            // ....
            db.AddToProducts(product);
        }
    }

    // the problem is Product and ContosoProduct have no arhitectural connection right now
    // so I cannot do this
    public void InsertProduct(ContosoProduct p)
    {
        Product product = (Product)p;

        using(SyncEntities db = new SyncEntities())
        {
            // ....
            db.AddToProducts(product);
        }
    }
}

ここで、ProductSynchronization はインターフェイスまたは抽象クラスになります。ProductSynchronization の多くの実装がある可能性が高いです。型をハードコードすることはできません。ContosoProduct、NorthwindProduct などのクラスは、サード パーティの XML から作成される可能性があります (そのため、引き続き逆シリアル化を使用することをお勧めします)。

ここで私が説明しようとしていることを誰かが理解してくれることを願っています。あなたが販売者であり、多数のプロバイダーがあり、それぞれが独自の独自の XML 形式を使用していると想像してください。もちろん、新しいフォーマットが登場するたびに必要になる開発は気にしません.10〜20個のメソッドを実装する必要があるだけなので、アーキテクチャをオープンにしてそれをサポートしたいだけです.

返信では、データ アクセス テクノロジではなく、設計に重点を置いてください。ほとんどのテクノロジは非常に簡単に使用できるためです (知る必要がある場合は、EF をデータベースとの対話に使用します)。

4

1 に答える 1

0

[編集: デザインノート]

わかりました。デザインの観点から、受信した xml に対して xslt を実行して、統一された形式に変換します。また、結果の xml をスキーマに対して検証するのも非常に簡単です。

xslt を使用すると、インターフェイスや抽象クラスには近づかず、コード内に 1 つのクラス実装 (内部クラス) だけを持つことができます。コードベースをきれいに保ち、データがあなたが述べたのと同じくらい単純であれば、xslt自体はかなり短くする必要があります。

変換の文書化は、プロジェクトの文書があればどこでも簡単に行うことができます。

xml ごとに 1 つのクラスが絶対に必要であると判断した場合 (または、1 人の顧客から xml ではなく .net dll を取得した可能性がある場合)、プロキシ クラスにインターフェイスまたは抽象クラスを継承させます (内部クラスに基づいて、プロキシ クラスで必要に応じてプロパティごとにマッピングを実装します。このようにして、任意のクラスを基本/内部クラスにキャストできます。

しかし、コードで変換/マッピングを行うと、コード設計が少し面倒になるようです。

[元の回答]

あなたが正しく理解している場合は、ThirdPartyProduct クラスを独自の内部クラスにマップする必要があります。

最初はクラスマッピングを考えています。Automapperなどを使用して、xml デシリアライズ プロキシを作成するときにマッピングを構成します。逆シリアル化を内部クラスと同じプロパティ名で終了させると、マッパーに対して行う構成が少なくなります。設定より規約。

この道に進むことについて、誰かの考えを聞きたいです。

別のアプローチは.ToInternalProduct( ThirdPartyClass )、 Converter クラスに を追加することです。そして、外部クラスを追加するにつれて、さらに追加し続けます。

3 番目のアプローチは、XSLT 担当者向けです。XSLT が好きなら、xml を内部の製品クラスに逆シリアル化できるものに変換できます。

これら 3 つのうちどれを選択するかは、プログラマーのスキルと、新しい外部クラスの追加を誰が維持するかによって決まります。XSLT アプローチでは、新しいフォーマットが登場しても、コードの再コンパイルやコンパイルは必要ありません。それは利点かもしれません。

于 2010-06-10T19:07:08.410 に答える