.net - ビジネスオブジェクトの DAL 設計

Question

ビジネスオブジェクトを設計するとき、データアクセス層を作成するさまざまな方法を試しました。いくつかは他のものよりもうまくいきましたが、私はいつも「より良い」方法がなければならないと感じていました.

人々がさまざまな状況で DAL を処理したさまざまな方法と、この手法がどのように機能したか、またはうまく機能しなかったかについての意見を知りたいだけです。

score 4 · Accepted Answer

私は現在、 Billy McCafferty の NHibernate Best Practices 記事 /多くの Web / WinForms アプリケーションのサンプルコードに大きく依存しています。これは、基本的な NHibernate と TDD を教えるだけでなく、優れた堅実なサンプルアーキテクチャを提供する、素晴らしく書かれた記事です。彼は、彼のアーキテクチャと設計に関する決定の概要を説明しようとしています。

彼は、ドメインオブジェクトごとに拡張できる汎用の DataAccessObjects を使用して非常に洗練された DAL を作成し、インターフェイスと DAOFactory を使用して BL に非常に疎結合します。特に NHibernate を使用したことがない場合は、最初に BasicSample を確認することをお勧めします。

この記事は NHibernate に大きく依存していますが、一般的なアプローチは他の ORM に合わせて簡単に変更できると思います。

score 2 · Accepted Answer

残念ながら、「より良い方法」があるとは思いません。使用する DAL アプローチについては、特定の状況に依存しすぎています。「最新技術」についての優れた議論は、Martin Fowler によるEnterprise Application Architecture のパターンです。

第 10 章「データソースアーキテクチャパターン」では、ビジネスアプリケーションで最も一般的に使用されるパターンのほとんどについて具体的に説明しています。

ただし、一般的には、基本的な保守性と適応性の要件を満たす最も単純なアプローチを使用することが最良の選択であることがわかりました。

たとえば、最近のプロジェクトでは、単純な「Row Data Gateway」だけで十分でした。(これは、CRUD 操作を実行するメソッドを含む、関連するデータベーステーブルごとにクラスを生成したコードにすぎません)。ORM とストアドプロシージャについての際限のない議論はありません。ただ機能し、必要な仕事をうまくこなしました。

score 1 · Accepted Answer

よくあるパターンがいくつかあります。「エンタープライズアーキテクチャのパターン」という本は、これらの良いリファレンスです。

テーブルデータゲートウェイ
行データゲートウェイ
アクティブレコード
データマッパー

llblgen などの ORM を使用する場合は、セルフサービスまたはアダプターを選択できます。

score 1 · Accepted Answer

NHibernate ルート (上記の @Watson からの良い記事リンク BTW) を使用する場合は、codebetter から suvius-flamingo サンプルプロジェクトをチェックアウトすることを強くお勧めします。彼は、MVC と NHibernate の動作を示す非常に優れた簡潔なサンプルプロジェクトを持っています。

これがsuvius-flamingoのリンクです。

score 1 · Accepted Answer

[更新] これは有効ではなくなりました。このプロジェクトのデザインが変更されました [/更新]

私たちのオープンソースプロジェクト Bunian では、ビジネスオブジェクト (コンポーネント全体) がシステムの中核であり、データアクセスレイヤーを含むすべてがビジネスオブジェクトを中心に展開する必要があると結論付けました。

ビジネスコンポーネントは、必要なものを他のユーザーに指示し、インターフェースを通じてそれを暗示します。たとえば、Business Object PersonにはIRepositoryForPersonというインターフェイスメンバーがあり、このメンバーには、必要に応じて Dependency Injection コンテナーを介してインスタンスが割り当てられます。

詳細については、こちらのブログ投稿を確認してください。

http://www.emadashi.com/index.php/2008/11/data-access-within-business-objects-bunian-design//

ここでBunianのコードをチェックしてください（まだアマチュアですが）：

http://www.codeplex.com/Bunian

もちろん、このアプローチでは、データアクセスセッションのライフサイクルのような新しいものが出現します (たとえば、NHibernate を使用している場合)。しかし、それは別の質問になると思います:)

これが役に立つことを願っています

score 1 · Accepted Answer

SQL にアクセスする DAL を作成することを意味していると仮定します。これは、今日最も一般的な部分であるためです。1つは、SQL に対して DAL を作成する際の最大の問題が ORM 部分である場合です。つまり、OO プログラミングとリレーショナルデータベーススキーマの間には基本的なインピーダンスの不一致があります。ORM を作成するための多くの素晴らしい、成功さえした試みがありました。しかし、それらはすべて、その利点である同じ問題に悩まされています。それらは、生成されている基礎となる SQL からユーザーを抽象化します。これが問題である理由は、データベースのパフォーマンスが、システム全体の機能の重要な要素であるためです。多くの (おそらくほとんどの) ORM は、多くの標準クエリのパフォーマンスが優れていないだけでなく、しかし、実際には、パフォーマンスを大幅に低下させる使用パターンを助長します (コレクションを照会するときにループ内でリレーションシップを繰り返しトラバースすることは、一般的な例の 1 つであり、デッドロックの解決を困難にすることは別の例です)。もちろん、ORM API を詳細に学習した後は、通常、これらのパフォーマンスの穴を回避する方法を見つけることができます。

ORM の現状に対する私の現在の見解は、データアクセスのすべての要点を処理する堅牢なライブラリの効率性を維持しながら、できる限り少ないことを望んでいるということです。言い換えれば、それらはまだ「十分」であるとは考えておらず、バックエンドとして SQL を使用することは決してないかもしれないため、ベアメタルレベルで制御を維持したいと考えており、SQL の記述に取り掛かります。 ORM に関係なく、多くの場合、ためらうことなく手を差し伸べることができます。これは、与えられたニーズに合わせてデータをクエリする具体的な方法を知っているためです。

これは明らかに、ORM を意図したとおりに宗教的に使用する場合よりもコーディングへの脆弱なアプローチであるため、ユニットテスト、SQL インジェクション、関心の適切な分離に関して特に注意を払う必要があります。つまり、要約すると、私はアッシュに同意しますが、それは彼/彼女が私に同意することを意味するものではありません:)

.net - ビジネス オブジェクトの DAL 設計

6 に答える 6

Related

Reference

.net - ビジネスオブジェクトの DAL 設計