私は初心者で、データベース アプリケーションの作成に取り掛かるときは、常にフォームを作成し、そこにすべてのコードとバインディングを配置しました。情報を保持する配列とリストを使用する代わりに、データベースに直接変更を加えました。
少し進化したので、顧客にウィジェットを販売し、販売情報をデータベースに保管しているとしましょう。データベースにアクセスするプログラムを書いている場合、これらのエンティティを操作するために「顧客」および「ウィジェット」タイプのクラスを作成したくないでしょうか?
私が間違っているとすれば、データベース アプリケーションをプログラミングするための適切なアプローチは何ですか?
はい。
あなたはn層プログラミングを調べたいと思っています。
基本的に、クラス ライブラリ (ビジネス層) へのフロント エンド (プレゼンテーション層) アクセスのみを許可します。次に、クラス ライブラリがデータベースにアクセスします。
これにより、緊密に結合されていないソリューションが得られ、より保守しやすいコードが可能になります。また、層を導入することで、ビジネス層とのインターフェースを変更する必要がない限り、フロントエンドでコードを書き直す必要なく DB を変更できます。
バインドに関する限り、Visual Studio Windows Forms (2005 以降) を使用している場合は、コントロールをバインドするために使用できるbindingSourceを使用できるはずです。ASP.NET を使用している場合、コントロールは問題なくオブジェクトのリストにバインドする必要があります。
ASP.Net の場合、ObjectDataSourceを調べる価値があるかもしれません。私自身は使っていませんが、ウェブ上にたくさんのサンプルがあります。こちらまたはこちらをお試しください。
プレゼンテーション層がデータベース構造に直接依存することは望ましくありません。それに関する問題は、データベース構造がまったく変更された場合、プレゼンテーション層を変更する必要があり、長期的には問題を引き起こす傾向があることです。さらに、プレゼンテーション層をデータベースと直接対話させることに関連するセキュリティの問題があります。
ここでの大まかな例えは市場です。一斤のパンを買うために店に行くとき、あなたは小麦を育てる方法を知る必要はありません。あなたが知る必要があるのは、あなたにはお金があり、彼らにはパンがあり、彼らは特定の量のパンを特定の金額と交換するということだけです。小麦を植える時期や、もみ殻を取り除く方法などを知る必要はありません。裏打ち層がそれを処理してくれるからです。同様に、農民はパンをたくさんの人に売る方法や、パンを作る方法さえ知る必要はありません。彼がしなければならないのは、小麦を育てる方法を知っていることだけです。
最新の設計哲学では、中間層を使用してプレゼンテーション層とデータベース層の間で対話することを推奨しています。これは、ビジネスロジックを配置する場所です。たとえば、サイトでウィジェットを販売しているとします。プレゼンテーションコードでデータベースにウィジェットを照会して表示する代わりに、ウィジェットを処理するビジネスオブジェクトがあります。このように、ビジネスオブジェクトはデータベース構造が何であるかを知る必要がありますが、プレゼンテーション層は、表示するウィジェットのリストをビジネスオブジェクトに要求する方法を知る必要があるだけです。さらに重要なことに、ビジネスオブジェクトに、特定のことが発生したときに呼び出されるルールを配置できます。したがって、注文時に在庫と注文のデータベースに直接変更を加えるプレゼンテーション層の代わりに、
このようにして、情報の表示を、Webサイトの基礎となる永続性およびロジックから分離します。関係するのは良い計画です。具体的には、任意の時点でWebサイトが何をするのか、そしてそれがビジネスオブジェクトが提供するインターフェイスの観点から何を意味するのかを理解する必要があります。次に、これらの要件に基づいてビジネスオブジェクトを実装します。これらのビジネスオブジェクトは、データベース構造と特定のビジネスロジック（「Aが発生したら、Bを実行してからCを実行する」など）の知識を配置する場所です。
これは最初は多くの余分な作業のように見えますが、それは本当に価値があります。