2011-02-02 9 views
6

私はSOAP API経由でファイルをWebベースのアプリケーションにインポートするツールを試作しており、C#インターフェイス経由でインポートしようとしているものをモデル化しているので、Webアプリケーションのモデルデータを扱うことができます。ドメインモデリング - プロパティまたはPOCOのインターフェイスを実装しますか?

public interface IBankAccount 
{ 
    string AccountNumber { get; set; } 
    ICurrency Currency { get; set; } 
    IEntity Entity { get; set; } 
    BankAccountType Type { get; set; } 
} 

internal class BankAccount 
{ 
    private readonly SomeExternalImplementation bankAccount; 

    BankAccount(SomeExternalImplementation bankAccount) 
    { 
     this.bankAccount = bankAccount; 
    } 

    // Property implementations 
} 

は、私はその後、私のためにBankAccounts私はそれらを必要とすべきを作成するIBankAccountまたは何とファクトリクラスのコレクションを返すのリポジトリを持っています。

私の質問は、このアプローチは私に多くの苦痛を与える原因となり、POCOを作成する方が良いでしょうか?私はこれを別のアセンブリに入れ、データアクセスとビジネスロジックを完全に分離したいと思っています。なぜなら、ここではデータがオンラインでどこに格納されるのかという動く目標を扱っているからです。

答えて

3

これはまさに私が使用している手法であり、私はこれまで何の問題も経験していません。私の設計では、データアクセス層から出てくるものはすべてインターフェイスとして抽象化されています(私はそれらをデータ転送規約と呼んでいます)。

public class CompositeEntity 
{ 
    static public CompositeEntity FromDataTransport(IFooData fooData, IBarData barData) 
    { 
     ... 
    } 
} 
:ドメインモデルのエンティティは、複数のデータコントラクトからデータを収集ところ、私はその後、それらのデータのトランスポート・オブジェクトからビジネスエンティティを作成するための静的メソッドを持っている私のドメインモデル..

interface IFooData 
{ 
    int FooId { get; set; } 
} 

public class FooEntity 
{ 
    static public FooEntity FromDataTransport(IFooData data) 
    { 
     return new FooEntity(data.FooId, ...); 
    } 
} 

ではそれは非常に便利ですあなたのデザインとは対照的に

、私は、データ転送契約の具体的な実装を作成するために工場を提供していないのではなく、値を書き込むためのデリゲートを提供し、具体的な作成に関するリポジトリの心配が

オブジェクトましょう

用法:

IFooData newFoo = FooRepository.Insert(f => 
    { 
     f.Name = "New Foo"; 
    }); 

ファクトリの実装は、私の意見でも同様にエレガントな解決策ではあるが。あなたの質問に答えるために、私は非常に似たアプローチの経験で、私は決して大きな問題に立ち向かうことはありません、そして、あなたはここで正しい道にいると思います:)

+0

ありがとうございました。リポジトリの挿入メソッドを使用してデリゲートを使用して、ファクトリを使用して具体的な実装を作成する方法をお勧めします。 –