データベースまたはデータアクセス層に複雑なオブジェクトを生成する必要がありますか？

Question

私は医療データを含む私たちの部署のためのアプリケーションに取り組んでいます。ここにあるサードパーティ製のシステムとのインターフェイスをとります。

オブジェクト自体（クレーム）はあまり複雑ではありませんが、データの性質とデータベースの構成上、クレームデータの取得は非常に複雑です。私は単純にすべてのテーブルを結合してデータを取得することはできません。クレームの基本を知るために「基本」クエリを実行し、さまざまな問題に基づいてクレームに関する補足データをまとめなければなりません。

それは、このデータを扱う際に良いだろう：

1. は、関連するすべてのデータが容易に利用可能であるストアドプロシージャ、内のオブジェクトを生成し、テーブル変数を反復処理（SQL Serverを使用して2005）を使用してすべての補足情報をまとめます。

2. データアクセスレイヤーでオブジェクトを生成します。データアクセスレイヤーでは、少しでも強力なデータ操作が可能で、検索データを取得するための素早く簡単な呼び出しを行います。

3. OR/Mツールを使用して、すべての複雑な状況をマップしてオブジェクトを生成します。

4. 何か他のもの。

編集：下記の問題のいくつかを明確にするために：複雑さは実際にはビジネス上の問題ではありません。クレームが "UB"のタイプコードである場合、表Xの補足データの一部を引き出す必要があります。クレームのタイプコードが "HCFA"の場合、テーブルYのデータの一部を取り出す必要がありますそれはそのようなものです。私はこれが役立つことを願っています

Answer 1

この場合、ストアドプロシージャをもう1つ選択してください。

あなたがモデル化しようとしているのは、クレームの概念を扱うアプリケーション間で一貫していなければならない非常に特定のビジネスロジック（「何がクレーム」なのか）です。

アプリケーションが1つしかない場合や、同じミドルウェアを使用する複数のアプリケーションの場合は、クライアントコードにそのアプリケーションを配置できます。しかし、実際には、データベースは、データベースがアクセスするソフトウェアに勝る傾向があることが示されています。

冗長な実装の微妙なバグやコーナーケースでは、さまざまなアプリケーションがわずかに異なる方法でデータを表示するようになります。ドライ、そしてそのすべて。

Answer 2

私は、ビジネスロジックを持続層にプッシュするファンではないので、私はオプション1をお勧めしません。私が取るアプローチは、基礎となるデータベースエンティティをモデル化した明確に定義されたプログラムオブジェクト、だからORM指向ですが、あなたの選択肢3は、私が本当にしない厄介なマッピング作業と考えているように思えます。私は、このオブジェクトをモデリングするプログラムオブジェクトのメソッドに設定したことを心配しているものをロードするために必要なロジックを持っています。

Answer 3

原則として、データアクセスレイヤーを使用して（場合によっては異なるソースから）データを取得し、それを意味のある方法で返します。

ビジネスルールやロジック（意思決定）を必要とするものはすべてビジネスレイヤーに入ります。

私は軽くその選択から逸脱していません。

あなたが生成している主張が実際には、意思決定やビジネスロジックなしに、さまざまな場所に格納されたデータのビューであるようです。そのような場合は、データレイヤー内のそのデータへのアクセスを管理する傾向があります。

**中央の作品で作業できる唯一の人がストアドプロシージャのエキスパートだったので、私は非常に複雑すぎる1つの巨大なシステムを忘れることはありません...ビジネスロジックの多くが終了しました*

Answer 4

私はセキュリティ上の理由からストアドプロシージャを使用します。使用しているクレームテーブルにSELECT権限を与える必要はありませんが、これはいくらか重要です。ユーザーには、そのストアドプロシージャへのアクセス権を与えるだけです。データベースユーザーがすでにテーブルに対するSELECT権限を持っている場合、データアクセスレイヤーでもオブジェクトを生成するのに間違いはありません。あなたが選んだオプションと一貫してください。ストアドプロシージャを他の場所で使用している場合は、ここで引き続き使用してください。同じことが、データアクセスレイヤー内のオブジェクトの生成にも当てはまります。

Answer 5

データを消費するさまざまな方法を考えてみましょう。アプリケーション層の目的は、あなたの人生を楽にすることです。そうでなければ、データベースで安全だと@hoffmandirtと同意します。

Answer 6

意思決定/ビジネスロジックを可能な限りアプリケーションのコード階層内で上位に押し上げます。 ORM /ストアドプロシージャは正常ですが、手書きクエリほど効率的ではありません。あなたのコードの上に行くほど、データがどのような目的で使用されているかを知ることができ、情報を知的に入手することができます。

Answer 7

Stored procedures are bad, m'kay?

ビュー、この場合のストアドプロシージャよりも良いだろうようですね。

.NETを使用している場合は、Linqのサポートを受けるためにORMをお勧めします。

一般に、データベースとアプリケーションコードの間にビジネスロジックを広げることは良い考えではありません。

最終的には、すべての解決策が有効です。あなたは、メイクやブレークのタイプの決定に直面していません。動かすだけで、この種の問題にぶつからないでください。