8

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

だから、私は質問を捨てます。データ アクセス層をどのように定義しますか?

4

8 に答える 8

9

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

于 2008-11-12T00:44:26.497 に答える
5

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

SomePage (ASP.NET ページ) と DataService (単純な古い C# クラス) の 2 つのクラスがある場合

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

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

于 2008-11-12T01:38:59.787 に答える
3

DAL の作成に関する次の記事を見つけました。

http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/

于 2010-08-10T14:36:53.003 に答える
2

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

于 2008-11-12T01:01:06.820 に答える
1

私は個人的に、DALをアプリケーションとデータベース間の相互作用が存在する場所として定義しています。そのため、DALと対話してCRUD操作を可能にするビジネスレイヤーがある場合があります。

EG私はDALと相互作用するModelClass.LoadAll（）メソッドを持っているかもしれません。それはデータをフェッチし、ModelClassは必要な方法でそのデータを使用します。

私はDALをできるだけ軽く保つことを好みますが、モデルデータの入力がDALで行われる別の方法を好む人もいます。

于 2008-11-12T00:36:55.887 に答える
1

データ アクセス層はデータにアクセスするだけで、他には何もアクセスしません。

于 2008-12-04T06:41:35.373 に答える
0

データを保持する「ブラックボックス」。ユーザーが気にかけている/そこにDBがあることを（考慮事項を除いて）伝えることができる場合、それは私が考えていることではありません

于 2008-11-12T00:34:42.413 に答える
0

このデータ リトリーバー(読み取り専用) レイヤーの設計を共有したいと思います。

アーキテクチャのキー:

  • アイデアは、get メソッドで取得されるデータを保持する、ほぼシングルトン (以下で説明) であるオブジェクトを作成することです。以下では、それをDRO( DataRetrieverObject) と呼びます。
  • クライアント オブジェクトが に簡単に到達できるようにする必要がありますDRO。
  • クラスを維持するのは簡単なはずです。

構造は三段構造を基本としています。

  1. DataRetrieverFactory必要なテーブルごとに 1 つずつ、(オーバーロードされた) 静的メソッドを使用します。オーバーロードを使用して、さまざまな種類のキーに一致させます。メソッドは DRO を返します。

  2. 実際の DRO を作成する2DataRetrieverFactory番目のクラスに建設ジョブを委任します。<TableNameAndKey>DR

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

    3.1. DRO が見つかった場合は、問題がないかどうかを確認します (意味:

    • 「古い」ものであってはなりません。
    • セッション実行に属している必要があります。
    • 等。）

    3.1.1. DRO に問題がない場合は、DRO を返却してください。

    3.1.2. DRO に問題がある場合は、オブジェクト (およびそのポインター) を削除し、データベースからのデータを使用して新しい DRO を作成します。ポインターをリストに格納します。

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

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

于 2012-04-10T12:03:45.813 に答える