2008-08-14 6 views
9

私は、新しいアプリケーションでデータレイヤを実装する最適な方法について、同僚との "ディスカッション"の途中です。データレイヤのベストプラクティス

視点の1つは、データレイヤーがビジネスオブジェクト(エンティティを表す独自のクラス)を認識し、そのオブジェクトでネイティブに処理できることです。

反対側の視点は、データ層は、オブジェクトに依存しないこと、および純粋に単純なデータ型(文字列、bools、日付など)を扱うべきであるということです

私は両方のアプローチが有効であることを見ることができますが、私の自分の視点は私が前者を好むことです。このように、データ記憶媒体が変更された場合、ビジネス層は新しいデータ層を収容するために(必然的に)変更する必要はない。したがって、SQLデータストアからシリアル化されたxmlファイルシステムストアに変更するのは簡単なことです。

私の同僚の視点は、データレイヤーはオブジェクト定義について知っている必要はなく、データが適切に渡されれば十分です。

これは宗教戦争を起こす可能性のある質問の1つであることは分かっていますが、そのようなことにどのように取り組んでいるかについてのコミュニティからの感謝を感謝します。 TIA

答えて

5

本当にあなたの世界観に依存しています。私は以前はカップルになっていないキャンプにいました。 DALはストーリーのBALにデータを供給するためだけにあった。

Linq to SQLやEntity Frameworkなどの新興テクノロジでは、DALとBALの間の線が少しぼやけています。 L2Sでは、特にDALは、オブジェクトモデルがデータベースフィールドに1-1のマッピングを持つため、ビジネスオブジェクトと密接に結合しています。

ソフトウェア開発の何かのように、間違った答えがありません。あなたはあなたの要件と将来の必要条件を理解し、そこから作業する必要があります。私はダカールラリーでフェラーリを使用することはもうありませんでした。

+0

私は全く同意します。データアクセスレイヤーのデザインはかなりぼやけています。私は常にプレゼンテーション層からあなたのビジネスロジックを分離することを選択します。 MVCパターンFTW ;-) –

1

このトピックをカバーして、私が持っている優れた書籍、

は、クリフトンノックにより、Data Access Patternsです。それはあなたのビジネス層をパーシスタンス層から切り離す方法に関する多くの良い説明と良いアイデアを持っています。あなたは本当にそれを試してみるべきです。私の好きな本の一つです。

0

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

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

これは、それは私が必要とするすべて、またはIListの<T>(のよりインテリジェントな実装のようだなら、私は昔ながらの一覧に渡すことができます:

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

私はこれを行いますObservableCollection <T>)をUIからバインドする予定がある場合は、このテクニックでは、ValidationResultのようなメソッドから、エラーメッセージが含まれている場合はそれを返します。

これは、私のデータレイヤーが私のオブジェクト定義を知っていることを意味しますが、それは私に余分な柔軟性を与えてくれます。私は今、新しいアプリケーションを作成した場合

0

チェックアウトLINQ to SQLは、私は完全にLINQベースのデータ層に頼って検討します。

これ以外にも、できるだけデータとロジックをデカップリングすることをお勧めしますが、それは必ずしも実用的ではありません。ロジックとデータのアクセスを完全に分離することで、結合や最適化が困難になり、Linqが非常に強力になります。

3

あなたは両方を持つことができます。データレイヤーにビジネスオブジェクトを知らせて、複数のタイプのデータソースで作業できるようにします。データとやりとりするための共通インタフェース(または抽象クラス)を提供する場合は、データソースの種類ごとに異なる実装を持つことができます。工場のパターンはここでうまくいく。

1

Jeffrey Palermoはこれについて良い記事を書いています。彼はそれをOnion Architectureと呼んだ。

0

私たちがNHibernateを使用するアプリケーションでは、XMLマッピング定義(どのテーブルがどのオブジェクトに属しており、どの列がどのフィールドに属しているかなどを指定します)が明確にビジネスオブジェクト層。

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

0

似たような情報を探していましたが、うまく説明できるthisに出くわしました。

関連する問題