データ層のベストプラクティス

Question

私は新しいアプリケーションにデータ層を実装する最良の方法について同僚と「議論」している最中です。

1 つの観点は、データ層がビジネス オブジェクト (エンティティを表す独自のクラス) を認識し、そのオブジェクトをネイティブに操作できる必要があるということです。

反対の観点は、データ層はオブジェクトに依存せず、単純なデータ型 (文字列、ブール値、日付など) のみを処理する必要があるということです。

どちらのアプローチも有効であることはわかりますが、私自身の見解としては、前者の方が好きです。そうすれば、データ ストレージ メディアが変更された場合でも、新しいデータ レイヤーに対応するためにビジネス レイヤーを変更する必要が (必然的に) なくなります。したがって、SQL データ ストアからシリアル化された XML ファイルシステム ストアに変更するのは簡単なことです。

私の同僚の見解は、データ層はオブジェクト定義について知る必要はなく、データが適切に受け渡されればそれで十分だというものです。

これが宗教戦争を引き起こす可能性のある質問の 1 つであることは承知していますが、このような問題にどのように取り組むかについてコミュニティからのフィードバックをお待ちしています。

TIA

Answer 1

それは本当にあなたの世界観次第です - 私は以前、非カップルキャンプにいたことがあります。DAL は、BAL にデータを提供するためだけに存在しました。これで話は終わりです。

Linq to SQL や Entity Framework などの新興テクノロジの人気が高まるにつれて、DAL と BAL の間の境界線が少し曖昧になってきています。特に L2S では、オブジェクト モデルがデータベース フィールドに 1 対 1 でマッピングされているため、DAL はビジネス オブジェクトと非常に密接に結合されています。

ソフトウェア開発の他の分野と同様、正解も不正解もありません。自分の要件と将来の要件を理解し、そこから作業する必要があります。私はサーキットデーでレンジローバーを使うのと同じように、ダカールラリーではもうフェラーリを使いたくありません。

Answer 2

両方持つこともできます。データ層にビジネス オブジェクトを認識させず、複数の種類のデータ ソースを操作できるようにします。データを操作するための共通インターフェイス (または抽象クラス) を提供すると、データ ソースの種類ごとに異なる実装を使用できます。ここではファクトリーパターンがうまくいきます。

Answer 3

このトピックを扱った、私が持っている優れた本は次のとおりです。 データアクセスパターン, 、クリフトン・ノック著。ビジネス層を永続層から分離する方法について、多くの優れた説明と優れたアイデアが含まれています。本当に試してみるべきです。私のお気に入りの本のひとつです。

Answer 4

Jeffrey Palermo がこれについて良い記事を書きました。彼はそれを呼んだ オニオン建築.

Answer 5

私が便利だと感じたトリックの 1 つは、データ層を「コレクションに依存しない」ようにすることです。つまり、データ層からオブジェクトのリストを返したいときはいつでも、呼び出し元にリストを渡してもらいます。したがって、これの代わりに:

public IList<Foo> GetFoosById(int id) { ... }

私はこれをします：

public void GetFoosById(IList<Foo> foos, int id) { ... }

これにより、必要な場合は単純な古い List を渡すことができ、UI からバインドする場合は IList<T> のよりインテリジェントな実装 (ObservableCollection<T> など) を渡すことができます。この手法を使用すると、エラー メッセージが発生した場合に、そのメッセージを含む ValidationResult などの情報をメソッドから返すこともできます。

これは依然としてデータ層がオブジェクト定義を認識していることを意味しますが、柔軟性がさらに 1 つ高まります。

Answer 6

Linq to SQL を確認してください。もし私が今新しいアプリケーションを作成しているとしたら、完全に Linq ベースのデータ レイヤーに依存することを検討します。

それ以外では、データとロジックを可能な限り切り離すことが良い習慣だと思いますが、それは常に現実的であるとは限りません。ロジックとデータ アクセスが純粋に分離されているため、結合や最適化が困難になります。これが Linq を非常に強力にしている理由です。

Answer 7

NHibernate を使用するアプリケーションでは、XML マッピング定義 (どのテーブルがどのオブジェクトに属するか、どの列がどのフィールドに属するかを指定するなど) が明らかにビジネス オブジェクト層にあるため、答えは「その間のどこか」になります。 。

これらは、ビジネス オブジェクトをまったく認識しない汎用データ セッション マネージャーに渡されます。唯一の要件は、CRUD のために渡されるビジネス オブジェクトにマッピング ファイルが必要であることです。

Answer 8

古い投稿ですが、同様の情報を検索していると見つかりました これ それをうまく説明しています。