0

アプリケーションをデータベースに接続するクラスが必要なプロジェクトを作成しようとしています。

Solidの原則に従って、オブジェクト指向の最良の方法でこれを行いたいです!

あなたへの私の質問は次のとおりです。

Provider をサブクラス (データベースから情報を取得するサブクラスとデータベースにデータを挿入できるサブクラスなど) に分割することは賢明でしょうか? それとも、これらの機能を 1 つの大きなクラスにまとめますか?

4

4 に答える 4

3

MartinFowlerのエンタープライズアプリケーションアーキテクチャのパターンをご覧になることをお勧めします。彼は永続性のパターンに関する素晴らしい章を持っています。

この問題は何度も解決されています。JPAやHibernateなどのORMソリューション、iBatisマッピング、SpringJDBCです。以前に行われたことをどのように改善するか想像できません。何が違うのか明確にできない場合は、新しいものに投資する前に、書かれ、テストされ、証明されたものを使用することをお勧めします。

必要な場合は、一般的なDAOをお勧めします。これは非常に単純なものです：

package persistence;

public interface GenericDao<K, V> {
    V find(K key);
    List<V> find();
    K save(V value);
    void update(V value);
    void delete(V value);
}
于 2012-11-06T12:50:09.023 に答える
3

私は、ORM が常に進むべき道であることに同意しません。

データベースの近くでプログラミングしたい場合、mybatisのようなクエリ マッパーは、ORM アプローチに代わる便利な方法です。

MyBatis データ マッパー フレームワークを使用すると、オブジェクト指向アプリケーションでリレーショナル データベースを簡単に使用できます。MyBatis は、XML 記述子または注釈を使用して、ストアド プロシージャまたは SQL ステートメントとオブジェクトを結合します。シンプルさは、オブジェクト リレーショナル マッピング ツールに対する MyBatis データ マッパーの最大の利点です。

mybatis はSpring によってサポートされており、あなたの生活をより簡単にします。

于 2012-11-06T12:52:40.340 に答える
1

DAOパターンを読むことから始めることができます。それがわかったら、 ORMフレームワークをさらに掘り下げます。

簡単な答え：はい、必ず特定のオブジェクト/クラスの永続化コードを一緒に保管してください。

乾杯、

于 2012-11-06T12:48:54.867 に答える
1

通常、これらのクラスは、機能（読み取り/書き込み）ではなく、オブジェクト（つまり、顧客、クライアント、車）で分割することをお勧めします。これはORMが使用するアプローチです。Javaの場合は特にHibernateORMフレームワークを見てください。

http://docs.jboss.org/hibernate/orm/3.5/api/

上記のドキュメント、あなたは間違いなくグーグルで良いチュートリアルを見つけることができます

于 2012-11-06T12:51:02.020 に答える