IRepository <T>およびRepository-Per-Entity

Question

私はエンタープライズアカウンティングアプリケーションのアーキテクチャを変更しています。私はIRepositoy <TDataModel>パターンを使用しますが、少し違いがあります。私は基底IRepository <TDataModel>から派生するすべての実体のためのインターフェイスを作るつもりです。私のエンティティはクライアント、製品と注文した場合、たとえば、その後、私は

IClientRepositoryを持っているでしょう：IRepository <ClientModel>
IProductRepository：IRepository <ProductModel>
IOrderRepository：IRepository <OrderModel>

public interface IRepository<TDataModel, TId> 
{ 
    TDataModel Get(TId Id); 
    IList<TDataModel> List(); 

    TDataModel Add(TDataModel Item); 
    TDataModel Add(TDataModel Item, IContext executingContext); 

    void Update(TDataModel Item); 
    void Update(TDataModel Item, IContext executingContext); 

    bool Delete(TId Id); 
    bool Delete(TId Id, IContext executingContext); 

    IList<TDataModel> Where 
     (System.Linq.Expressions.Expression<Func<TDataModel, bool>> criteria); 
} 


public interface IProductRepository : IRepository<DataModel.Product, int> 
{ 

} 

理由私はいくつかのエンティティのCreationDateを設定するなど、BALではなくDALにいくつかのドメインモデルの属性を設定したいと思っています。 ？）

私はいくつかのIRepository <サンプルを見ましたが、この組み合わせを使用するものは見つかりませんでした。私はこれを行うには良いことがあることを知りたいですか？それはまったく正しいのですか？他の長所と短所は何ですか？事前に

おかげで

Answer 1

私はそれはあなたが作成日をどのように考えるかに依存しますね。それはドメインの一部であるかどうか？ドメインロジックは値に依存しますか？

たとえば、「代理で作成する」機能が必要ですか（作成者と作成日は現在のユーザーと現在の時間と同じではありません）。バックアップからのデータの復元で元の値が保持されない場合、何か問題はありますか？作成日がクライアントのタイムタイム、サーバーの日時またはデータベースの日時のどちらであるかは重要ですか？

上記の答えがNOの場合は、 ）作成日はドメインの一部ではないため、外部で設定することができます B）本当に必要ですか？もしそうなら、私はインフラストラクチャの問題、つまりキャッシュ管理、変更通知などを推測しています。そうですか？