mysqlなどのRDBMSを使用しながらオブジェクト指向アプローチを使用する方法について質問があります。請求を追跡する小さなアプリケーションを開発しています。これはJavaに組み込まれており、MySQLデータベースを使用してデータを保存しています。私のアプリケーションには、コスチュームと製品クラスがあります。これで通常、配列または異なるデータコンテナを使用して永続的なデータストレージを処理している場合、顧客クラスと製品クラスに更新、削除などがあります。しかし、私はこれまで以上に静的な方法を使用していることに気づきました。たとえば、顧客の配列がないため、顧客情報を含むデータベースがあるだけです。顧客（または製品）ベースの静的メソッドを呼び出すだけで、顧客オブジェクトを削除するだけでは意味がありません。プライマリIDです。
皆さんにお願いしたいのは、RDBMSを使用するときにオブジェクト指向のアプローチをどのように取るかということです。
オブジェクト指向の原則を使用してJavaクラスを設計します。
SQLと正規化の原則を使用してDBを設計します。
次に、オブジェクト/リレーショナルマッピングという課題に全速力で取り組みます。:-)
HibernateやIbatisのようなテクノロジーは、これを支援するために特別に設計されており、十分に文書化された問題です。Springのような追加のテクノロジーは、それらの使用を非常に簡単で快適に操作できるようにします。
永続性をDAO（データアクセスオブジェクト）レイヤーに抽象化します。たとえば、VehicleやAnimalのようなクラスがたくさんある場合は、VehicleDaoやAnimalDaoのようなDAOを使用して、DBとの通信方法と基本的な動作を区別します。あなたのシステム。
FWIW、私はまさにこれを行うことを提唱しています。アプリ側での優れたアプリ設計、データ側での優れたDB設計です。これが完了すると、DBとの間でクラスデータを永続化および取得するときに2つをマップする方法が常にあります。これは、個々のレイヤーの1つを危険にさらして他のレイヤーを「支援」するよりもはるかに優れたIMOです。
データベースはビジネスオブジェクトを表します-完全に正規化されているなど。
オブジェクトモデルは、コード内のデータをどのように処理する必要があるかを表します。これらは通常同じではありません。たとえば、顧客テーブルがアドレステーブルに1対多でリンクされていますが、コードでは両方のタイプの情報を含むオブジェクトを使用します。
データアクセスオブジェクト（DAO）は、ビジネスオブジェクト（つまり、読み取り/書き込み）を処理します。サービスレイヤーは、必要に応じてDAOの出力をオブジェクトに結合して、作業を完了します。サービスレイヤーは、必要に応じてトランザクションも処理します。
サービスレイヤーからデータアクセスを抽象化すると、コードの保守、データベーススキーマの更新、およびテストが容易になります。
DTO（データ転送オブジェクト）（この場合はデータベース内のオブジェクトを表すクラス）を使用することは、単一責任の原則に従います。これは、OOPの原則（より具体的にはカプセル化のプロセス）に基づくデザインパターンです。これにより、各クラスが1つの目的のみを達成することが保証されます。ビジネスロジックをSQL文字列内に保持すると、保守が困難になり、DRYの「Don'tRepeatYourself」の原則に違反します。私の経験から、ORMはシステム設計のプロセスを促進しました。NHibernateを試してください。http://geekswithblogs.net/pariam/archive/2006/07/26/86352.aspx
このアプリケーションが今後も成長すると予想される場合（おそらくアプリケーションの99％）、オブジェクトを作成します。削除が単一のSQL呼び出しである場合でも、将来的にロジックを追加する必要がある場合があります（子テーブルの行の削除、監査データの保存、ハード削除ではなく論理削除への移行など）。
データベースとoo-codeの取り扱いは、常にホットなトピックです。そして、 「ただいけない」と言う人もいるかもしれません。
私はそれらに同意しませんが、そうしなければならなかったときに私は多くの問題を見てきました。私は、HibernateのようなORマッパーをすぐに推奨する他のいくつかに完全に同意しません。多くの場合、開発中は実際には何のメリットもありませんし、実行時に多くの問題（パフォーマンス、エラー診断）が発生します。
いつものように、それはすべてあなたがあなたのアプリで何をしているかに依存します。あなたは、顧客オブジェクトがないと言います。どうしてこれなの？たとえば、GUI内のテーブルにすべての顧客を表示し、ユーザーが右クリックなどでこれらの1つを削除できる場合、最善のアプローチは、JDBCを介してDBデータを読み取り、それをJTableに入れてJDBCを再度使用する静的削除メソッド。
ただし、アプリ内で実際に顧客と取引する場合は、顧客オブジェクトを確立してから、ORマッピングが必要になります。ただし、フレームワークは必要ありません。手書きのsql/JDBCは、ほとんどの場合、優れた機能を果たします。
私の観点からすると、OR-Mapper-Frameworksは、パフォーマンスが面白くなく、他のほとんどの場合、DBに関するすべてのこと（つまり、プロトタイピング）について考える気がないアプリケーションでは良いことです。読み取りと保存のための手書きコード付き。
ドメインモデルは良いアプローチです。ビジネスロジックを、データベースに直接依存しないレイヤーに分離します。SOLIDの原則を使用して、ドメイン駆動設計を見てください。このようにして、分離され、簡単にテストできる読み取り可能なOOコードが得られます。「リポジトリ」のようなパターンは、リレーショナルデータベースの現実を操作しながら、ビジネス要件に焦点を合わせ続けるのに役立ちます。基本的に、次のように定義してインターフェースします。
List<Customer> customers = Customers.WithOutstandingOrders(DateRange range)
次に、このインターフェイスをデータアクセス層（ドメイン外）に実装します。最も簡単な方法は、HibernateのようなORMを使用することです。このアーキテクチャでのデータベースの役割は、「ビットバケット」のようなものです。言い換えると、ほとんどのロジックはオブジェクト指向コードに存在し、データベースはデータの異常から保護し、処理を高速化します（正規化、参照整合性、およびインデックスを使用）。