1

私は、データ、ビジネス、およびプレゼンテーション層で構成される最初のレイヤードアプリケーションを設計しています。

私のビジネスコンポーネント（たとえば、Business.Components.UserComponent）には、現在次のメソッドがあります。

public void Create(User entity)
{
    using (DataContext ctx = new DataContext())
    {
        ctx.Users.AddObject(entity);
        ctx.SaveChanges();
    }
}

私はこのデザインが好きです。ただし、次の実装を推奨するいくつかの例をオンラインで見つけました。

public void Create(User entity)
{
    // Instanciate the User Data Access Component
    UserDAC dac = new UserDAC();
    dac.InsertUser(entity);
}

これにより、すべてのエンティティのデータアクセスコンポーネントが作成され、それぞれに基本的なメソッド（作成、編集、削除など）が含まれます。

基本的なメソッドと、データアクセスコンポーネントのメソッドを呼び出すだけのビジネスコンポーネントを使用してデータアクセスコンポーネントを作成する必要があるため、これは二重の作業のように見えます。

レイヤードアプリケーションで基本的なCRUD機能を適切に実装するためのベストプラクティスと見なされるものは何ですか？それらはビジネスコンポーネントまたはデータアクセスコンポーネントで「コーディング」する必要がありますか？

4

1 に答える 1

1

場合によります。ビジネスレイヤーが最初のアプローチに従うよりも単純にCRUD操作を実行することを期待している場合。ビジネスコンポーネントが多くのエンティティと連携するビッグビジネスロジックを使用する場合は、2番目のアプローチの方が適しています。

人々が2番目のアプローチを使用することを好む理由は、テストと永続性の無知です。最初のアプローチを使用する場合、ビジネスコンポーネントはEntityFrameworkと緊密に結合されています。ObjectContextのモックは非常に簡単な作業ではないため、テストは困難です。2番目のアプローチを使用する場合、ビジネスレイヤーは永続レイヤーから独立しています。簡単にテストでき、必要に応じて永続レイヤーを変更することもできます。しかし、これらは、おそらく現時点では探していない、より高度な概念です。コードをテスト可能にするには、さらに改善が必要です。

DACはリポジトリとして実装することもできます。クラスが1つだけで、リポジトリをインスタンス化するときにエンティティタイプを定義するように、ジェネリックリポジトリを作成する方法はたくさんあります。

var repository = new GenericRepository<User>();

また、個別のデータアクセス層を使用すると、複数のリポジトリ間で単一のコンテキストを共有することが合理的である場合があるため、新しい複雑さが生じることにも注意してください。これは、作業単位パターンとして知られているものと一緒になります。

インターネット上でのリポジトリと作業単位のパターンの実装に関する記事はたくさんあります。私はそれらのいくつかを自宅でお気に入りとして保存しているので、興味があれば後で私の答えにそれらを含めることができます。

于 2010-09-03T08:13:44.867 に答える