データアクセス層を定義する

StackOverflow https://stackoverflow.com/questions/282622

  •  08-07-2019
  •  | 
  •  

質問

GUI、ビジネスロジック、データアクセスを明確に区別する必要があることは誰もが知っているようです。私は最近、常にクリーンなデータアクセスレイヤーを持つことを自慢しているプログラマーと話をしました。このコードを見たところ、彼のデータアクセスレイヤーは、少数のSQLメソッド（ExecuteNonQueryやExecuteReaderなど）をラップする小さなクラスにすぎません。ページの背後にある彼のASP.NETコードで、彼はpage_loadおよびその他のイベントに大量のSQLをハードコーディングしています。しかし、彼はデータアクセスレイヤーを使用していると誓っています。

だから、私は質問を投げます。データアクセスレイヤーをどのように定義しますか？

役に立ちましたか？

解決

同僚が話していることは、ほとんどの人が考えるDALではありません。 DALは、動的SQL、ストアドプロシージャ、またはIRepositoryなどのORMによって実行されるかどうかにかかわらず、データベースへの呼び出しをカプセル化する必要があります。 WebページにSQLやビジネスロジックを含めることは絶対にしないでください。さもないと、メンテナンスの悪夢になります。

他のヒント

.NETの非常に簡単な例は次のとおりです。

2つのクラスがある場合： SomePage（ASP.NETページ） そして DataService（これは単純な古いC＃クラスです）

SomePageが常にDataServiceを呼び出してデータの読み取り/書き込みを行う場合、データアクセスレイヤーがあります。 SomePageには、SQLまたはSystem.Data.SqlClientクラスへの参照は含まれません。

ただし、SomePageは、DataServiceクラスとの間で受け渡されるDataSetまたはビジネスオブジェクトを使用できます。

他の人が言ったことに加えて、私は通常、あなたのデータがどのように保存されているかを抽象化する場所と考えています。非常に優れたデータアクセスレイヤーを使用すると、Oracle、SQL Server、Access、フラットテキストファイル、XMLなどを自由に交換でき、他のアプリケーションレイヤーに対して透過的になります。つまり、データアクセス層と他の層との間のコントラクトは、データベースに依存しない方法で定義する必要があります。

個人的に、アプリケーションとデータベース間の相互作用が存在する場所としてDALを定義します。したがって、DALとやり取りしてCRUD操作を許可するビジネスレイヤーがあります。

EG DALとやり取りするModelClass.LoadAll（）メソッドがあり、データをフェッチし、ModelClassはそのデータを必要な方法で使用します。

DALを可能な限り軽量に保つことを好みますが、DALでモデルデータの生成が行われる他の方法を好む人もいます。

データアクセスレイヤーはデータにアクセスしますが、他には何もありません。

A <！> quote;ブラックボックス<！> quote;データを保持します。ユーザーが気になっている/そこにDBがあることを伝えることができる場合（考慮事項ごとを除く）、それは私が考えていることとはまったく異なります

このデザインのデータ取得機能（読み取り専用）レイヤーを共有したいと思います。

アーキテクチャのキー：

  • アイデアは、getメソッドで取得したデータを保持する、ほぼシングルトン（以下で説明）のオブジェクトを作成することです。以下では、DRO（DataRetrieverObject）と呼びます。
  • クライアントオブジェクトがDataRetrieverFactoryに到達するのは簡単なはずです。
  • クラスのメンテナンスは簡単なはずです。

構造は3段階の構成に基づいています。

  1. 静的なメソッド（オーバーロード）を持つ<TableNameAndKey>DRを使用します。必要なテーブルごとに1つです。オーバーロードを使用して、異なる種類のキーを一致させます。メソッドはDROを返します。

  2. <=>は、実際のDROを作成する2番目のクラス<=>に構築ジョブを委任します。

  3. <=>には、DROへのポインタの静的リストがあります。リストをループして、特定のキーを持つDROが既にあるかどうかを確認します。

    3.1。 DROを見つけた場合-OKかどうかを確認します（意味：

    • <！> quot; old <！> quot;、
      • であってはなりません
    • セッション実行に属している必要があります、
    • など）

    3.1.1。 DROに問題がない場合-DROを返します。

    3.1.2。 DROが正常でない場合は、オブジェクト（およびそのポインター）を削除し、データベースのデータを使用して新しいDROを作成します。リストにポインタを保存します。

    3.2。ポインターのリストにヒットがない場合、DBからのデータを使用して新しいDROを作成し、ポインターを静的リストに格納します。

この手法を使用すると、必要に応じてDROを再利用できますが、クラスのインスタンスをたくさん持つことができるため、クラスはシングルトンではありません。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top