設計DALとBLL - 新しいマルチティアアプリケーションを設計しながら、私は私の<strong>DAL</strong>と<strong>BLL</strong>層設計のための意思決定をする難しさに直面しています関連テーブル

Question

用シングル/複数のデータリポジトリ。

私は、従業員情報がマスターテーブルと1-1および1-Manyの関係を持つ複数のテーブルに分散しているとします。いくつかを以下に示します：Employee_Skill、
Employee_Experience

は、DALのレベルでは Employee_Education、
を

従業員（マスター表）、
Employee_Contact_Detail、
、私は、GETALLのような共通の機能を提供する汎用的なデータリポジトリを持っています各テーブルのGetSingle、Add、Edit、Deleteを実行します。今

は、私は、「汎用データリポジトリ」に由来し、私の「従業員データリポジトリ」を設計し、この中でGetEmployeePersonalDetail、GetEmployeeContactDetail、GetEmployeeEducation、AddEmployeePersonalDetail、EditEmployeePersonalDetailなどのような単一のクラスでは上記のすべての関連テーブルのための機能を追加する必要があります私は "Generic Data Repository"のメリットはあまり得られません。もう1つの方法は、各テーブル用に別々のデータリポジトリを作成し（そして汎用リポジトリから派生させて）、従業員用のビジネスロジックレイヤで単一のクラスを作成することです。

EDIT

私は別のビジネスロジックを作成する場合、私は、DALのレベルでは、オプションの「表ごとに別々のデータリポジトリ」のために行くと、代わりに「従業員」のための「単一のビジネス・ロジック・クラス」の場合クラスは、各データリポジトリに対応して、シナリオを見て卑劣なアプローチになるでしょうか？

ご利用いただきありがとうございます。

Answer 1

あなたの質問へのコメントで述べたように、これは私の意見です。

問題：あなたはすでにベースのリポジトリを使用している場合

、なぜ各テーブルの特定のリポジトリを作成しますか？繰り返しになりますが、BLLでは、各リポジトリに別々のServiceクラス（上記の "ビジネスロジッククラス"）を作成しています。これはすべて繰り返し作業であり、管理し理解するのは難しいです。

提案：あなたが使用しているORM（もしあれば）

言及していません。 ORMが以下のアーキテクチャを実装するために必要な機能を提供していると仮定します。
DALを汎用リポジトリで閉じることをお勧めします。特定のテーブルに対してDALクラスを記述しないでください。すべてのサービスクラスは、基本的なCRUD関数に汎用DALを使用します。すべての拡張機能は、サービスクラス自体で実装する必要があります。

リポジトリ/テーブルごとに1つのクラスを作成するのではなく、サービスクラスについては、やり直し作業が繰り返されます。 1つのサービスで関連する複数のテーブルをグループ化すること（上記の段落を参照してリポジトリの問題を解決する）。

たとえば、すべてのテーブルの基本機能を提供する汎用DALを作成します。すべての従業員関連テーブルをカバーするEmployeeServiceを作成します。すべての会計関連テーブルをカバーするAccountServiceを作成します。同様に、ログ関連のすべてのアクティビティについてはLogServiceです。これにより、関連するすべてのメンバーを1つのクラスにまとめるため、サービスとのやりとりが容易になります。これにより、繰り返し作業も削減されます。

私のthisとthisの質問とその回答を参照してください。

これがあなたの懸念を説明することを願っています。

編集1

あなたのコメントに記載されているとおり、EFです。私が提案したものを実装するのに必要な機能をサポートしています。段ロール

Yesと重複する代わりに、DALのBLLの拡張機能を実装

。します。反対側も同じです。各テーブルにDALを書くと、実際にDALにBusiness Logicが流出しています。ビジネスロジックが変更された場合は、意味をなさないDALを変更する必要があります。
私の提案では、レイヤーが重なっていても、懸念事項はまだ分かれています。 DALはCRUDのみを処理します。 BLLは、データベースロジックを含むすべてのロジックを処理します。

いずれのプロジェクトでも同じ戦略を使用しましたか？

はい。以前のいくつかのプロジェクトでは、一般的なDALの代わりに各テーブルごとに個別のDALを作成していました。これは大きな反復作業を引き起こしました。たとえプロジェクトが比較的小さいにもかかわらず、メンテナンスのオーバーヘッドが増えました。数ヶ月前に、私は上記で提案したものを実装した比較的大きなプロジェクトから始めました。今私たちに与えられた救済を見ることができます。