2009-08-25 22 views
1

現在のクライアント用に作成したいくつかのアプリケーションでは、ユーザーアカウントを共有しています。つまり、あるアプリケーションの各アカウントが他のアプリケーションに存在する必要があります。
各アプリケーションには独自の設定があります。
アプリケーションの数と設定自体は、時間の経過とともに実際に変更される部分なので、それらを分けたいと思っています。この状況でどのようなパターンを使用する必要がありますか?

データストアは、IRepositoryクラス(XMLRepository、SQLRepositoryなど)を介してアクセスします。 彼らは実際のデータアクセスロジックを抽象化します。 ISettingsクラスのフィールドは、種類ごとに異なるものになりますので がSettingsServiceクラスが続い

public T GetSetting<T>(IUser user) where T : ISetting 

としてISettingクラスを得ることができる必要があり、私はそれがだ、それを埋めるために方法を知っておく必要があり、実際の設定のクラスだと数えるう値を取得する方法はわかりません。
しかし、リポジトリはデータにアクセスする方法を知っていますが、リポジトリの配置場所はわかりません。

私が誤解していない場合、GetSettingは実際にはファクトリメソッドです。私はこの問題が新しいことではないと感じているし、おそらくこれを解決する良いパターンがある。

私のオプションは何ですか?

答えて

0

リポジトリから返されたデータから具体的なSomeSettingインスタンスを作成できる、具体的なタイプのISettingには、ある種のファクトリが必要です。

どのようにそのようなファクトリが機能するかは、設定​​の永続性スキーマの構想によって異なります。それぞれのタイプのISetting用のカスタムスキーマがありますか、またはBLOB/XMLで設定をシリアライズしてデシリアライズするだけですか?

最初のケースでは、各設定スキーマのカスタムリポジトリが必要です。これは簡単なシナリオです。各専用リポジトリは単にカスタムファクトリとして機能するためです。

また、メタデータをBLOBと一緒に保存して、BLOBの逆シリアル化に使用するカスタムファクトリを格納するか、シリアライズされたBLOBの型を保存することができます。 NETを使用してオブジェクトを直列化および逆シリアル化します)。

+0

私は自分のリポジトリ(各ISetting実装の専用リポジトリ)にカスタムマッピングロジックが必要だと言っています。 Linq2Sql生成クラスのメタデータにはすでにこのデータがあるので、2番目のアプローチを試してみます。 –

+0

これはサーバーファームの構成設定で行います。構成を表形式でシリアル化し、シリアライズされた型のアセンブリ修飾名も含めます。これにより、BLOBをデシリアライズすることができます。しかし、バージョン管理の問題を見てください。 –