2

Entity Framework を使用して新しい Address を作成するために使用するもの:

Op1:

IRepository<Address> _addressRepository;

また、Address Entity を使用してデータベースと直接やり取りします。

Op2:

public bool CreateAddress(AddressDto addressDto);

そして、サービス メソッドに話しかけて、新しいアドレスを挿入します。

問題は、プロジェクトの長期的なメンテナンスにおいて、誰かが何かを変更し、それに依存する別のコードを壊すリスクが存在しないことをより保証するのはどれですか?

あなたの経験に基づいて、どれが最良のアプローチですか?

4

2 に答える 2

1

私の経験では、2 番目のオプションが最適です。私は、サービスの消費者に影響を与えない方法でビジネス ロジックを実装および適応できるサービス ファサードを持つことが大好きです。ところで、サービスには、ドメイン サービス、Web サービス、Web API などがあります。基本的に、一部の消費者が呼び出すことができるメソッドを公開するだけの、ビジネス ロジックとデータ アクセスに関するシェルです。

私の見解では、リポジトリ メソッドを公開すると、多くのことがわかります。消費層がリポジトリの実装について知っているのはなぜですか? そして、リポジトリ パターンに永遠に縛られることになります。EF と (汎用) リポジトリについては、多くの議論がありました。個人的には、汎用リポジトリは嫌いです。私は総根の観点から考えるのが好きです。エンティティ タイプごとにリポジトリを用意するのは、多くの場合、1 つのレイヤーが多すぎるため、邪魔になるだけです。DbSeta のDbContextは基本リポジトリです。コンテキストは、作業単位として完全に適合します。私は、リポジトリや作業単位を調整する代わりに、サービス メソッドで直接コンテキストに目を向ける傾向があります。もちろん、リポジトリを使用できますが、サービス ファサードの背後に隠します。

最後に 1 つ: サービス メソッドから単にブール値を返すのではなく、メソッドの失敗/成功に関する情報を含むオブジェクトを返します。たとえば、Web API の HttpResponse です。

于 2013-03-19T22:48:08.307 に答える
0

次のようなリポジトリを使用してみてください。

 public class Repository<T> : IRepository<T> where T : class
{
    protected DbSet<T> DbSet;

    public Repository(DbContext dataContext)
    {
        DbSet = dataContext.Set<T>();
    }

    #region IRepository<T> Members

    public void Insert(T entity)
    {
        DbSet.Add(entity);
    }

    public void Delete(T entity)
    {
        DbSet.Remove(entity);
    }

    public IQueryable<T> SearchFor(Expression<Func<T, bool>> predicate)
    {
        return DbSet.Where(predicate);
    }

    public IQueryable<T> GetAll()
    {
        return DbSet;
    }

    public T GetById(int id)
    {
        return DbSet.Find(id);
    }

    #endregion
}

また、Adress の新しいインスタンスが必要な場合は、リポジトリを呼び出してこれを実行してください。

var adressRepository = new Repository<Adress>(yourDataContext);

AddressRepository で次のようにします。

adressRepository.Insert(yourAdressObject)

最後に、コンテキストの SaveChanges を呼び出します。

yourDataContext.SaveChanges();
于 2013-03-19T20:06:58.040 に答える