2

私たちのアプリケーションは、私たちの管理下にないデータスキーマを使用して別のシステムへのユーザーインターフェイスを提供します。このアプリケーションは、CSLAを使用してビジネスオブジェクトを作成し、サードパーティシステムのデータを編集できるようにします。ただし、サードパーティのデータスキーマが進化するにつれて、それとともに進化する必要があります。ただし、お客様はいつでも、異なるデータスキーマを備えたサードパーティシステムの任意のバージョンを使用できます。したがって、アプリケーションは、顧客がたまたま持っているスキーマのサポートされているバージョンに適応できる必要があります。

これを解決するために、おそらく戦略パターンを使用することを検討しました。基本的に、データスキーマの最下位バージョンをサポートする基本クラスを持ち、その後、後続の各バージョンをサポートする派生クラスを持ちます。次に、データスキーマの現在のバージョンに対応するクラスを返すファクトリがあります。ただし、これが引き起こす可能性のある、長くて紛らわしい継承チェーンの可能性を懸念しています。この問題を解決するためのより良い方法はありますか?おそらく継承の代わりに構成を使用しますか?

このhttp://securesoftwaredev.com/2009/05/31/supporting-multiple-versions-of-a-data-model/を処理するための可能な方法を概説するこの投稿を見つけました

このアプローチが私たちに役立つかどうかはわかりませんが、何かを実装する前に他のアイデアを得たいと思っていました。

4

2 に答える 2

2

CSLA .NETを使用すると、データアクセスロジック(DAL)をアプリケーションの他の部分から簡単に分離できます。

CSLAを使用して、データベースの形状ではなく、問題のドメインにマップするビジネスオブジェクトを作成する必要があるため、DALは、データベースへのアクセスと、必要に応じてデータをビジネスオブジェクトにマップすることを考慮する必要があります。

2つの異なるデータベーススキーマがある場合は、おそらく2つのDAL実装があり、どちらもデータベースにアクセスして、データをまったく同じビジネスタイプにマップします。

「 CSLA4の使用:データアクセス」の電子ブックはこれをかなり広範囲にカバーしており、ProjectTrackerサンプル(バージョン4.0以降)は、概念を示す抽象的なDALも使用しています。

于 2013-02-11T06:37:32.850 に答える
0

プラグ可能なDAL層でファクトリ実装を使用する方法を見ていきます。通常、これを利用して、単体テスト用にさまざまなデータベースサーバーまたはモックデータをサポートできますが、さまざまなデータモデルをサポートすることもできます。

于 2013-01-30T04:57:56.080 に答える