ORMフレームワークを応用して残されたデータベースに対してモデル設計を行ういくつかのテクニックについて話します.

多くのプロジェクトの開発は既存のデータベースに基づいて開発されています.残されたデータベースの存在はjavaモデルとデータモデルの間の障害を増加させた.
多くの友人がhibernateや他のJdbc wrapperの開発フレームワークを選ぶかどうか迷っている.
実は、hibernateのようなormツールを使うのは結局賢明な選択で、もちろん唯一の賢明な選択ではありません.私はこの文章を書くのは、まだためらっている人に自信の力を提供して、断固として自分の決定を下すことができることを望んでいます.
ある友人は残されたシステムに対してモデル設計をする問題を尋ねたことがある.简単にこの问题に答えるのは难しいですが、私はいくつかの経験を提供することができます.同时に、この招待状をその友达に対する完全な答えとして、彼に役に立つことを望んでいます.
統一的な業務ロジックに対して、業務モデルに対して、DAO/Serviceはそれぞれ精巧な継承体系を設計する.
多くの友人は、残されたシステムがビジネスモデルの継承システムを効果的にサポートすることは難しいと考えているため、慎重な態度を持っています.
彼らの懸念は理にかなっており,通常,残留システムは既存のORMのクラス継承システムをサポートできない.しかし、残されたシステムはサポートされておらず、ビジネスモデルのスムーズな使用クラス継承を阻害し、DRYの目標を達成することはできません.抽出した抽象モデルはDRYをより容易に実現できるとともに,この中のビジネスモデルの階層設計は「ビジネス統合処理」のニーズを真に反映している場合が多い.
このような設計は興味深い局面が現れ、業務モデルは継承体系のモデルであり、データモデルは一対一マッピングのテーブルモデルであり、このような設計で業務を処理する際、特に「統一的な抽象的な業務論理」を処理する際、継承モデルをサポートするテーブルモデルよりも多くの努力を払って達成することができる.多くの友达はずっとこの“多く払う”努力が恐ろしいかどうかを心配しています.本当に心配しないでください.あまり努力していません.DAOやあなたのサービスモジュールの中で、的確な継承的な設計をする必要があります.この合理的な継承システムのDAO/serviceモジュールにより、テーブルモデルが継承システムをサポートしていないビジネスモデルによる問題を減らすことができ、完璧に補うことができます.
一般的に、DAO/Serviceにはこのような階層があるほうがいいです.

BaseService<----UserService,OrderService

class BaseService { update,create,delete,findById..} 

各サブクラスの最終的なCRUDがbaseServicesを通過することを保証する.CRUDが完成します.
このようなDAO/Serviceクラスの階層設計は、私たちが設計したビジネスモデルの継承システムに「武術の場」をもたらしました.baseServiceのこの場所では、「統一的に処理する必要がある」ビジネスロジックをここに置くことができます.代表的な点は、

class abstract BaseService extends HibernateDAOSupport {

     public void create(Object o){
                 if(o instanceof PublishableModel){
                           publish((PublishableModel)o);
                  }
                 getHibernateTemplate().save(o);
    }

}

違和感があるようですが、「意味」のあるコードです.PublishabeModelという抽象クラスは、ビジネスモデルの中で統一的に処理できるビジネス抽象モデルを表しています.このコードは、次のとおりです.

   if(o instanceof PublishableModel){
                           publish((PublishableModel)o);
                  }
 

このビジネスモデル抽象体系に本当に役割を果たす「武力行使の場」を与えた.
経験のある開発者として、いつでもどこでも「DRY」の趣旨を一貫して堅持し、貫徹しなければならない.