プレゼンテーション層がデータベース構造に直接依存しないようにする必要があります。その問題は、データベース構造がまったく変更され、プレゼンテーション層が変更されなければならず、長期的には問題を引き起こす傾向がある場合です。さらに、プレゼンテーション層がデータベースと直接対話することに伴うセキュリティ上の問題があります。
ここでの類推は市場です。パンを買うために店に行くときは、小麦の栽培方法を知る必要はありません。あなたが知る必要があることは、お金があり、パンを持っており、ある程度の量のパンを交換することだけです。あなたは、小麦を植える時期、または籾殻を取り除く方法、またはそのいずれかを知る必要はありません。バッキング層がそれを処理するからです。同様に、農業従事者は、パンを一人一束に売る方法や、パンを作る方法さえ知る必要はありません。彼がしなければならないことは、小麦の栽培法を知ることだけです。
中間層を使用してプレゼンテーションレイヤーとデータベースレイヤーをやりとりすることをお勧めします。これはビジネスロジックを置く場所です。たとえば、サイトにウィジェットを販売しているとします。プレゼンテーションコードでデータベースにウィジェットを照会して表示させる代わりに、ウィジェットを処理するビジネスオブジェクトがあります。このようにして、ビジネスオブジェクトはデータベース構造が何であるかを知る必要がありますが、プレゼンテーション層はビジネスオブジェクトにウィジェットのリストを表示する方法を知る必要があります。さらに重要なことは、ビジネスオブジェクトでは、特定のことが起きたときに呼び出されるルールを配置することができます。したがって、プレゼンテーション層がインベントリと注文のためにデータベースを直接変更する代わりに、ビジネスオブジェクトは変更の方法と、プレゼンテーションレイヤが売り上げの発生を要求するときに変更するテーブルを知っています。
このようにして、情報の表示とWebサイトの基礎となるロジックとの分離を行います。関与しているのは良い計画です。具体的には、特定の時点でWebサイトが何をしているのか、ビジネスオブジェクトが提供するインターフェイスの意味を理解する必要があります。次に、それらの要件に基づいてビジネスオブジェクトを実装します。それらのビジネスオブジェクトは、データベース構造と特定のビジネスロジックの知識を置く場所です(「Aが起きたとき、BとCをやる」など)。
これは最初の追加作業のようですが、実際にはそれは価値があります。
Visual Studioと.NETでバインディングやその他のデータ機能を使用するのはどうですか?プレゼンテーションレイヤーにフィードするために "データアクセス"レイヤーを使用する場合は、データアクセスレイヤーのほとんどのコードを最初から書き込んでいないでしょうか? – Pete
使用しないでください。 .NETの前にはじめて導入されて以来、私はいつも基盤となるデータベースへのバインディングフロントエンドコントロールがEvilだと感じました。私の意見では、もちろん.... – RolandTumble
申し訳ありませんが、データベースとやりとりするためにスクラッチからクラスを作成し、そのクラスにフィールドを設定するためにデータベースクラスを使用する別のクラスを作成したいと思いますか?これは、フォームにテキストボックスとラベルを投げ、コントロールをバインドするよりも好まれますか? – Pete