これは少し主観的な質問なので、主観的な回答を以下に示します。それを行うための正しい方法は1 つではありません。私が個人的にどのように作業するのが好きかについてのみ話すことができます (大きなプロジェクトのバージョン、小さなプロジェクトの場合は別の話があります)。あなたやあなたのチームにとって、それは異なるかもしれません。
参考までに、私は主にアジャイルに取り組んでいます。たとえば、要件は変更される可能性があります。コード内の API は変更される可能性があります (頻繁に変更されます)。もちろん、これは、私が自分の個人的な仕事に役立つと考えるものと、役に立たないと考えるものに影響を与えます.
また、私は可能な限り大きな枠組みを使わずに仕事をしたいと思っています。そのため、以下で説明するモデルにはフレームワークがありません。
データベースの作業を3 つの部分に分けて作業します: ( MVC パターンとかなり似ています)
- 実際のデータベース バックエンド(SQL を実行できる)。クロスプラットフォーム作業用の独自のコードを含めることができます。
- アプリケーション固有の情報を格納するストレージ クラス。各情報は、ストレージ クラスから読み取ったり設定したりできます (例:
interface AddressBook型の要素へのアクセスを提供しますinterface Contact。これには、いくつかのものに対するゲッターとセッターがあります。実装は、それをバックエンドの単一のテーブルに変換します)。
- 実際の作業を実行し、アプリケーションに応じてさらに分割されるアプリケーション コード(例: アドレス帳 GUI を提供するものなど)。
なぜ私はそのように分割するのですか？その理由の 1 つは、新しいストレージまたはデータベース バックエンドに簡単に切り替えられることです。新しい要件を満たすためにテーブルを再構築するときにパフォーマンスが向上する可能性があることがわかった場合は、ストレージ クラスを更新します。そうすれば、アプリケーション ロジックに触れる必要はありません (例: メール アドレス用の 1:n テーブルをアドレス帳に追加します。新しいテーブルとその関係は、アプリケーション内のコードには影響しません。メールのリストを受け取ることができます)。連絡先からアドレスを取得し、簡単に追加または削除できます)。
もう 1 つの理由は、アプリケーション コードが読みやすく (アプリケーション コードで構成されているため)、ストレージ コードも読みやすい (格納、キャッシュなどの処理のみを行うため) ことです。
3 番目の理由は、別のストレージ メカニズムを追加したい場合 (たとえば、データベース バックエンドが組み込まれたプラットフォームに切り替える場合や、オプションの Web サービスを追加する場合)、3 つのレイヤーですべての OOP メカニズムを使用できるためです。たとえば、複数のストレージを同じアプリケーション内に共存させることができるため、ユーザーはデータをローカルに保存するか (データベース バックエンドを備えたストレージ)、クラウドに保存するかを選択できます。
この回答が、アプリケーションのデータベース関連部分における OOP の可能性についての洞察に少しでも役立ったことを願っています。繰り返しますが、これは正しい方法の 1 つではありません。