.net - データレイヤーのベストプラクティス

Question

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

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

反対の見方は、データ層はオブジェクトにとらわれず、純粋に単純なデータ型 (文字列、ブール値、日付など) を処理する必要があるというものです。

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

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

これが宗教戦争を引き起こす可能性のある質問の 1 つであることはわかっていますが、そのような問題にどのように取り組むかについて、コミュニティからのフィードバックをいただければ幸いです。

ティア

score 5 · Accepted Answer

それは本当にあなたの世界観に依存します-私はかつて非結合キャンプにいました. DAL は BAL にデータを提供するためだけにありました - 話の終わりです。

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

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

score 3 · Accepted Answer

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

score 1 · Accepted Answer

私が持っている、このトピックを扱った優れた本は、Clifton Nock によるData Access Patternsです。ビジネスレイヤーを永続レイヤーから分離する方法について、多くの優れた説明と優れたアイデアがあります。ぜひ試してみてください。それは私のお気に入りの本の一つです。

score 1 · Accepted Answer

Jeffrey Palermo がこれについて良い記事を書いています。彼はそれをオニオンアーキテクチャと呼んだ。

score 0 · Accepted Answer

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

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

私はこれをします：

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

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

これは、データ層がオブジェクト定義を認識していることを意味しますが、柔軟性が 1 段階高くなります。

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

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

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

score 0 · Accepted Answer

古い投稿ですが、同様の情報を検索すると、これに出くわし、うまく説明されています。

.net - データレイヤーのベスト プラクティス

8 に答える 8

Related

Reference

.net - データレイヤーのベストプラクティス