このような4層プロジェクトを作成しています
- データ アクセス層
- ビジネスロジックレイヤー
- エンティティに関連する POCO クラスのみを含むドメイン モデル (EF5 経由)
- フロントエンドとしてのウェブサイト
私は今まで常に DAL と BLL を混ぜ合わせ、Web サイトから直接 DAL を参照してきました。今回は、ここで懸念事項を実際に分離したいと思います。実際の DAL であり、永続性にとらわれない BLL と組み合わせて単体テスト可能な DAL を作成したいと考えています (プロが行うように) 計画中です。 EF5の使用について
私は多くのサイトを読みました
- http://architects.dzone.com/articles/implementing-repository
- http://www.codeproject.com/Articles/37155/Implementing-Repository-Pattern-With-Entity-Framew
- http://www.codeguru.com/csharp/article.php/c19335/Guide-to-Implement-the-Factory-Pattern-in-C.htm
- http://geekswithblogs.net/cdpcodingblog/archive/2012/04/17/a-simple-pattern-to-separate-business-logic-from-data-access.aspx
- http://blogs.microsoft.co.il/blogs/gilf/archive/2008/05/03/abstract-factory-pattern.aspx
- http://www.dotnetrangers.net/2011/05/01/common-design-patterns-in-c-4-0-part2-abstract-factory-pattern/
- ビジネス層内で Unit of Work/Repositories を使用する正しい方法は何ですか?
- Entity Framework と MVC は、ビジネス レイヤーまたはデータ アクセス レイヤーで DbContext を作成します。
基本的に、ファクトリ、リポジトリ、および作業単位のパターンを使用する必要があることはわかっていますが、何がどこにあるのか、何が単純なのかわかりません (ただし、十分に明確な例) 従うことができます
私が知っていることは、ウェブサイトで DAL を参照するべきではないということですが、ブリッジの作成方法が本当にわかりません。
たとえば、Product テーブルと Order テーブルの例はありますか?